Re: [Mono-dev] wifi network access

[Juan Cristóbal Olivares]

You can use dbus-sharp: https://github.com/mono/dbus-sharp

I created a small project as an example: https://github.com/juancri/DbusTest

Let me know if you need any help. Regards,

On Tue, Dec 16, 2014 at 4:16 AM, techi eth  wrote:
>
> Hi,
>
> Please let me know how can i access wifi network data using mono on Linux.
>
> On windows i can fond library provide api interface to do the same.
> http://msdn.microsoft.com/en-us/library/ms706556(v=vs.85).aspx
>
> Thanks
>
>
>
>
>
>
>
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>

-- 
Atte,
Juan Cristóbal Olivares


*cxsoftware.com *
Skype: cxsoftware6001
Celular: +56-9 9871 7277
Central: +56-2 2938 0060
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] After an initial investigation of porting WCF to mono, this is what I've found so far

[Miguel de Icaza]

My quick take, as I am about to bird a plane:

- ifdef out transactions
- SR missing stuff is pretty common, we have been stubbing these out, check
the recent commits to mono/mcs/class/System to get an idea
- use reference source for the landing spot.

On Tuesday, December 16, 2014, Bernie Schoch  wrote:

> References to XAML configuration #if XAML out
> References to COM  #if COM out
>
> There are references to Transaction processing in Microsoft namespace is
> this something we need to support or #if it out?
>
> There is a ton of stuff missing from System.IdentityModel:
> This is where the majority of the errors lie. 100+ items;  Should I just
> back port this into existing Mono code or use reference source versions?  I
> ask because I don't have much history on mono project and don't really know
> status of System.IdentiyModel.
>
> What is the strategy to deal with SR messages?  Right now I've just
> created an internal SR and InternalsSR class
>
> Thanks,
> Bernie Schoch
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] After an initial investigation of porting WCF to mono, this is what I've found so far

[Bernie Schoch]

References to XAML configuration #if XAML out
References to COM  #if COM out

There are references to Transaction processing in Microsoft namespace is
this something we need to support or #if it out?

There is a ton of stuff missing from System.IdentityModel:
This is where the majority of the errors lie. 100+ items;  Should I just
back port this into existing Mono code or use reference source versions?  I
ask because I don't have much history on mono project and don't really know
status of System.IdentiyModel.

What is the strategy to deal with SR messages?  Right now I've just created
an internal SR and InternalsSR class

Thanks,
Bernie Schoch
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Open source .Net, and TLS 1.1 & 1.2

[Edward Ned Harvey (mono)]

> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
> boun...@lists.ximian.com] On Behalf Of Edward Ned Harvey (mono)
> 
> > From: Miguel de Icaza [mailto:mig...@xamarin.com]
> >
> > We would love a test case to add to the test suite.
> >
> > We are building a new test suite as part of this work anyways.
> 
> This is almost done.  Granted it is microscopic in scope - the test I've 
> written
> tests only for the case that I know fails; it's far from being a generalized 
> test
> for the SslStream class as a whole.

Well, this grew up more than expected.  I started writing a unit test, and 
discovered the behavior is variable based on the existence or non-existence of 
intermediates and roots on *both* the client and server...  Which means in 
order to test it thoroughly, the client & server cannot be on the same 
machine...  So it's really not a unit test.  Even more dramatically, the 
behavior depends on whether the server & client are windows or mono.  So 
ultimately this test requires 4 machines (2 windows and 2 mono) with 16 tests 
run on each combination.

I wrote a compatibility testing project.
https://github.com/rahvee/MonoSslStreamServerBug

In this project, I created a junk root CA, an junk intermediate CA, and a junk 
server cert, suitable for publishing and testing.  I also tested, offline, 
pasting some real root CA, intermediate, and real commercially signed certs, 
and found the behavior of real certs from real CA's to be consistent with the 
results of these generated junk certs.

There are ultimately 2 bugs causing mono to fail - (1)  The server doesn't send 
the chain to the client.  And (2) the client fails to build a chain from 
available certs, even if all the necessary certs are available to the client.  
I noticed "mcs/class/Mono.Security/Mono.Security.X509/X509Chain.cs" doesn't use 
the intermediate store at all, when using the "Build()" method to build a chain.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Open source .Net, and TLS 1.1 & 1.2

[Jonathan Pryor]

On Dec 15, 2014, at 6:54 AM, Edward Ned Harvey (mono) 
 wrote:
> I'll look into __MonoCS__ to see if it does what I'm looking for.

It is not what you're looking for. __MonoCS__ is defined by the Mono C# 
compiler (mcs); that's all it means.

It doesn't mean that you're building on Linux or Windows (Mono + mcs runs on 
Windows). It doesn't control which runtime mcs is running within (mcs runs 
within .NET as well as Mono). It doesn't control what runtime you're running in 
(mcs output runs on .NET).

About the only use for __MonoCS__ is if you hit an mcs bug and want to work 
around it.

 - Jon

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list