Service Name - PPPOE Connection

Aug 9, 2012 at 11:09 PM
Edited Aug 10, 2012 at 2:59 PM

Hello,

I searched in all documentation of the project and i could not solve my doubt.

Is there any way to change the "Service Name"  in my PPPOE connection by DotRas?

To find the field "Service Name", click the right mouse button in your PPPOE connection, then "Properties". Then go to the tab "General"

I also wanted to get the pppoe error code if the connection fails (629, 691, etc ...). is it possible?

(sorry for english...)

Coordinator
Aug 11, 2012 at 1:59 AM

The "Service Name" seems to map to the PhoneNumber property on the RasEntry class. You can change this once you create the PPPoE connection by simply modifying the phone number property before you add it to the entries property, or you can change it after it is in a phonebook and call the Update method on the entry.

string path = RasPhoneBook.GetPhoneBookPath(RasPhoneBookType.User);

RasPhoneBook pbk = new RasPhoneBook();
pbk.Open(path);

var device = RasDevice.GetDevices().Where(o => o.DeviceType == RasDeviceType.PPPoE).First();
RasEntry entry = RasEntry.CreateBroadbandEntry("My PPPoE Entry", device);
entry.PhoneNumber = "Test Service";

pbk.Entries.Add(entry);

Regarding your other question, the error code will be attached to a RasException which gets thrown if a problem occurs during a connection attempt.

 

Aug 14, 2012 at 2:04 PM
Edited Aug 14, 2012 at 2:08 PM

Hi!

thanks for you answer about the service name. works perfectly.

by the way, about the question of the error code, based on his explanation, i try this code:

	Dim dialer As New RasDialer

        Try
            dialer.DialAsyncCancel()
            credentialTyped = New NetworkCredential(username.Text.ToString(), password.Text.ToString())
            dialer.Credentials = credentialTyped
            dialer.EntryName = "MyProvider"
            dialer.PhoneBookPath = RasPhoneBook.GetPhoneBookPath(RasPhoneBookType.AllUsers)

            dialer.DialAsync()

        Catch ex As Exception

            My.Computer.FileSystem.WriteAllText("log.txt", ex.ToString & Chr(10), True)

        End Try

even when I type a wrong password, or unplug the cable from the network card, nothing is written to the file log.txt.

in this case, the errors should not be thrown to the file?

(sorry for english...)

Coordinator
Aug 14, 2012 at 11:47 PM

Dialing asynchronously using DialAsync would, under most circumstances, cause the exceptions to be bubbled up through an event. Unless something specific happens when attempting to dial the connection (the entry not existing for example) no exceptions would be thrown there. They would instead be passed to the DialCompleted event once the connection is cleaned up and released.

If you were to dial synchronously using the Dial method rather than DialAsync any exceptions would be caught where you're trying to catch them.

Aug 15, 2012 at 1:59 PM
Edited Aug 15, 2012 at 2:00 PM

Yes. I understand how it works and captured the error codes.

Now, for information, I was testing my dialer in windows xp and windows 7 and have been generated errors. I managed to fix, but the code has some differences for the two systems:

RasPhoneBook pbk = new RasPhoneBook();

Windows XP:

pbk.Open()
RasPhoneBook.GetPhoneBookPath(RasPhoneBookType.AllUsers)

Windows 7:

pbk.Open(true)
RasPhoneBook.GetPhoneBookPath(RasPhoneBookType.User)

In this case, I check what operating system user. You can tell because the difference in the two systems? In WXP I can access the catalog of all phone users, as in W7 it is not possible (even running with administrator privilege).

I am using VB.net.

(sorry for english)

Coordinator
Aug 16, 2012 at 1:36 AM

Well, that's due to the introduction of the UAC in Vista and later only allowing access to the All Users profile folder if the application has elevated rights. Running as administrator privileges doesn't fix the problem (if the UAC is still enabled), you need to get your application to request elevated execution rights (which forces that prompt by Windows for the user to confirm). This is a Windows thing, nothing I or DotRas could do to circumvent that.. nor would I even if it was possible.

You'll need to work out dealing with the UAC if you want the application to run on Vista or later operating systems.

Aug 16, 2012 at 9:22 PM

Got it. I've thought that was it. Anyway, thanks for the explanations and congratulations for the DotRas project. Very good.

Editor
Aug 23, 2012 at 9:01 PM

We're in the midst of moving our (relevant to this project) systems to 7. What is the use of the all users phonebook in 7 and Vista if administrator is the only one which can see it (and then only with UAC)? If we want the equivalent, can we create a phonebook somewhere else and ACL it so that it is world-writable and use that instead?

(Our stuff explicitly needs the ability to create phonebook entries which are readable by all, though we can do the actual writing behind the scenes with a [escalated] service as necessary.)

Coordinator
Aug 23, 2012 at 10:08 PM

Hey Keith,

It can still be used to store phonebook entries that are accessible by all users on the machine, they just don't have write access to it. If the application writing to the All Users profile folder has the appropriate permissions, it can do so. You can see this difference when creating new entries in Windows 7 that when you click the checkbox to make the new entry available to all users, the UAC prompts you for confirmation and checks your rights to make write changes to the file.

As long as the application that wants to make write changes to the has the appropriate permissions it can do so, you won't need UAC authorization to read data from the file which depending on your application may be all the rights a normal user would need.

You do have the option of storing the phonebook entries your application needs in a location other than the standard profiles included with Windows. You simply need to pass it a different path to the RasPhoneBook.Open method.

Editor
Aug 27, 2012 at 7:01 PM

I just wondered if changing the file permissions on rasphone.pbk was enough, is that so?

Coordinator
Aug 28, 2012 at 2:10 PM

Not sure, that probably depends on your environment and what you set the permissions to. I'm not sure what the UAC hooks into for the phone books, it could be file based or it could be keeping an eye on that profile folder.

Editor
Nov 6, 2012 at 7:09 PM

Sorry for the thread ressurect, but I've finally gotten to the point I mentioned above. There seems to be something else going on ... I've ACL'd the c:\programdata\microsoft\network\connections\pbk\rasphone.pbk, to contain a Full Control permission for Users per my question earlier. This does not seem to do the trick. Instead, when I call pbk.Entries.Add(entry) this fails with an UnauthorizedAccessException when a non-administrator runs my application ... What is missing here? I've also added the same ACL change to the directory ... Later on, pbk.Entries.Remove() also fails the same way  - I accidentally allowed it to fall through - but perhaps it will be important later.

Barring me not getting something with the ACLs, it looks like one needs administrator rights period to change the system phonebook. Darn. 

Coordinator
Nov 8, 2012 at 10:37 PM

As long as the application has elevated rights, and the user account that is running the application has rights to the folder, it should be fine. Of course, this is heavily dependent on your environment whether there is any additional security on the folders being applied through group policies and the like.

What operating system are you using that's causing the problem, Vista, 7, 8?

Editor
Nov 9, 2012 at 1:57 PM

7.

What you say about the application asking for elevated rights is interesting. I'm not too up on that sort of stuff - what would that do, prompt for administrator credentials? If so, we can't have that - it has to be silent and and run in the ordinary user context, which (now) is not an administrator. I've gone and implemented it via our Windows service that I needed for other things (e.g. on demand device enables), so it doesn't matter so much, but knowing other mechanisms would be helpful anyway. Fortunately System can do the change, it seems.

Coordinator
Nov 9, 2012 at 2:21 PM

This might be a helpful resource: http://support.microsoft.com/kb/981778

It describes how to self-elevate an application to a higher privilege level than normal. Which, to the best of my knowledge, is required on Vista and later operating systems in order to change connections in the all-users profile phonebook. Think of it as the button on the Task Manager under the processes tab for "Show processes from all users" that has the UAC shield next to it, it'll work the same way as that. As long as the application is elevated, and the user has the appropriate security access to the file (check the security tab when right clicking the file and going to properties) it should work. Unless your environment adds additional security beyond what is normally there.

Also, have you considered using a custom phonebook instead? I was thinking about this earlier this morning. You wouldn't have to worry about the UAC or any of the fun associated with process elevation, and the entries wouldn't show up in the network connections window (unless you really wanted users to be able to dial the connections manually).

Editor
Nov 9, 2012 at 2:30 PM

From the page:

"However, interactive administrators can self-elevate by giving explicit consent with the Consent UI. Interactive administrators perform administrative tasks that include installing software and drivers, changing system-wide settings, viewing or changing other user accounts, and running administrative tools."

These users aren't administrators of any kind, so the above approach won't work. (Though I'll look at the code anyway, since I should learn about this stuff for other reasons.) I read something else this morning about how using a distinct process is the recommended approach (after all, that's why services exist anyway!). As for the custom phonebook, would it be sharable by all users forever? We often reassign machines, and I don't think we'd want to recreate any changes to the phonebook, not to mention that technicians have to use it, and they have different credentials.

Coordinator
Nov 9, 2012 at 3:33 PM

The custom phonebook is really just a file you would have sitting next to your application that you could deploy along with it, or create during runtime. Though depending on where you have this file sitting, and if you're trying to modify it during runtime, may or may not require you to elevate application privileges. Also, be aware this may have an impact on credentials used to dial connections if you're storing them in the phonebook in your application.

Consider this:

You have your application installed to "C:\Program Files\YourApp" you also have your installation package drop your Custom.pbk file for your phonebook along with your installation that has your entry pre-configured in it. If you want a user to make a change to this phonebook, and due to it being in the Program Files folder, your application will need to request elevated privileges to modify that particular file. If you have, say your phonebook dropped into the shared ProgramData folder (it's hidden, and I forget what the special directory name for this is called in C#) you should be able to modify the file without any headaches.

If you have your application deployed to a different folder, for arguments sake say "C:\Temp\YourApp", the security considerations required for modifying files underneath Program Files is negated, but opens up other security concerns if someone messes around with your file that shouldn't be. That's what the UAC is supposed to be ensuring doesn't happen for files that are under its protection.

It really depends on your application, and what kind of security you want guaranteeing the safety of your phonebook file. If someone gets their hands on the file, outside your applications control, would that cause a security breach in your network? If so, perhaps being a bit more restrictive on accessing the file would be worthwhile. Those are the kinds of questions you might want to answer amongst your team.