Re: [rfc] removing the NDISulator

[Thomas Mueller]

> On 24.10.2013 05:46, Thomas Mueller wrote:
> > I have motherboard (MSI Z77 MPOWER) with Realtek 8111E Ethernet that fails 
> > to
> > connect in FreeBSD or OpenBSD, OK with NetBSD-current and Linux, and
> > Atheros AR9271 onboard wifi: device athn is included in NetBSD (current 
> > only)
> > and OpenBSD.

> > Tom
> For your problems with Realtek 8111E chipset please have alook at 
> http://lists.freebsd.org/pipermail/freebsd-net/2013-October/036935.html
> Maybe this patch isn't for you but you need to do something similar to
> add support.
 
> Regards,
> Maciej

Where does the patch begin and end?  Does it include a and b in apparent path?

Is the first line 
diff -git
and the last line just before
--
?

Do I save that to a file, go to $SRCDIR and
patch  ?

I would also like to see if I can connect by wifi using
Hiro H50191 USB-stick WLAN adapter (RTL8191SU chip) using device rsu.

Tom

___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: [rfc] removing the NDISulator

[Maciej Milewski]

On 24.10.2013 05:46, Thomas Mueller wrote:

I have motherboard (MSI Z77 MPOWER) with Realtek 8111E Ethernet that fails to
connect in FreeBSD or OpenBSD, OK with NetBSD-current and Linux, and
Atheros AR9271 onboard wifi: device athn is included in NetBSD (current only)
and OpenBSD.

Tom
For your problems with Realtek 8111E chipset please have alook at 
http://lists.freebsd.org/pipermail/freebsd-net/2013-October/036935.html
Maybe this patch isn't for you but you need to do something similar to 
add support.


Regards,
Maciej

___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: [rfc] removing the NDISulator

[Kevin Lo]

Thomas Mueller wrote:
  

The later driver model isn't supported by ndisulator. We'd have to
implement all the newer NDIS stuff for wifi and ethernet.
 

In the later NDIS layer the Microsoft Wireless Services implement a bunch
of stuff that used to be up to the driver. Ie, the driver just exposed an
ethernet "device" with some extra bits for wifi. Ie, the whole stack runs
in the driver. That has changed.
 
...



This is why I'd rather us bite the bullet now and deprecate it, versus have
it in there and put in the work to upgrade it to handle NDIS 6.x drivers
with the Microsoft wireless extensions stuff.
 


-adrian

How much extra work would there be to update the ndis(ulator/wrapper)?

Would it be more than writing native FreeBSD drivers which might be ported
from NetBSD, OpenBSD and Linux?

What about cases where specifications might be a trade secret?

How difficult is it to port or write a wifi or Ethernet driver for FreeBSD?

I have no experience writing device drivers but have some experience with C and 
C++.

I notice NetBSD and OpenBSD have drivers for some chips that FreeBSD lacks.

I have motherboard (MSI Z77 MPOWER) with Realtek 8111E Ethernet that fails to
connect in FreeBSD or OpenBSD, OK with NetBSD-current and Linux, and
Atheros AR9271 onboard wifi: device athn is included in NetBSD (current only)
and OpenBSD.


No offence, but you have mentioned several times that Realtek 8111E Ethernet
and athn(4) do not work on FreeBSD, just wondering why you don't sit down
and start coding then all your questions will be answered.



Tom




Kevin
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: [rfc] removing the NDISulator

[Thomas Mueller]

 
> The later driver model isn't supported by ndisulator. We'd have to
> implement all the newer NDIS stuff for wifi and ethernet.

> In the later NDIS layer the Microsoft Wireless Services implement a bunch
> of stuff that used to be up to the driver. Ie, the driver just exposed an
> ethernet "device" with some extra bits for wifi. Ie, the whole stack runs
> in the driver. That has changed.

...

> This is why I'd rather us bite the bullet now and deprecate it, versus have
> it in there and put in the work to upgrade it to handle NDIS 6.x drivers
> with the Microsoft wireless extensions stuff.



> -adrian

How much extra work would there be to update the ndis(ulator/wrapper)?

Would it be more than writing native FreeBSD drivers which might be ported 
from NetBSD, OpenBSD and Linux?

What about cases where specifications might be a trade secret?

How difficult is it to port or write a wifi or Ethernet driver for FreeBSD?

I have no experience writing device drivers but have some experience with C and 
C++.

I notice NetBSD and OpenBSD have drivers for some chips that FreeBSD lacks.

I have motherboard (MSI Z77 MPOWER) with Realtek 8111E Ethernet that fails to
connect in FreeBSD or OpenBSD, OK with NetBSD-current and Linux, and
Atheros AR9271 onboard wifi: device athn is included in NetBSD (current only)
and OpenBSD.

Tom

___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: [rfc] removing the NDISulator

[Adrian Chadd]

On 23 October 2013 15:31, Vincent Hoffman  wrote:

>  On 23/10/2013 18:35, Eitan Adler wrote:
>
> On Mon, Oct 21, 2013 at 6:29 PM, Adrian Chadd  
>  wrote:
>
>  If there are drivers that people absolutely need fixed then they should
> stand up and say "hey, I really would like X to work better!" and then
> follow it up with some encouraging incentives. Right now the NDISulator
> lets people work _around_ this by having something that kind of works for
> them but it doesn't improve our general driver / stack ecosystems.
>
>  I doubt most people prefer to use the ndisulator over a native driver.
> However, many people don't have the skills, time, or money to provide
> the incentives you are talking about.  At this point ndisulator
> provides a means to an end: working wireless and it isn't causing
> significant strain on the project in terms of development effort.
>
> Our end users are not always developers and I think removing this
> feature will hurt more than it will help.
>
>
>
>  As an end user, the main issue I have is that according to the manpage it
> supports ndis 5.1
> According to
> http://en.wikipedia.org/wiki/Network_Driver_Interface_Specification this
> is the version supported by
> Windows XP , Server 
> 2003,
> Windows CE  4.x, 5.0, 6.0
>
> As you might guess most new devices wont be coming with drivers for XP, so
> does this mean I wont be able to use drivers for a recent windows version
> (my understanding is that it will but happy to learn differently)
> If this is the case and there is no active development on it, a gradual
> depreciation over the 10.x series is probably a good idea. If however its
> likely to support current drivers/devices it does have a place (I've used
> it once or twice in a pinch.)
>

This is why I'd rather us bite the bullet now and deprecate it, versus have
it in there and put in the work to upgrade it to handle NDIS 6.x drivers
with the Microsoft wireless extensions stuff.



-adrian
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: [rfc] removing the NDISulator

[Vincent Hoffman]

On 23/10/2013 18:35, Eitan Adler wrote:
> On Mon, Oct 21, 2013 at 6:29 PM, Adrian Chadd  wrote:
>> If there are drivers that people absolutely need fixed then they should
>> stand up and say "hey, I really would like X to work better!" and then
>> follow it up with some encouraging incentives. Right now the NDISulator
>> lets people work _around_ this by having something that kind of works for
>> them but it doesn't improve our general driver / stack ecosystems.
> I doubt most people prefer to use the ndisulator over a native driver.
> However, many people don't have the skills, time, or money to provide
> the incentives you are talking about.  At this point ndisulator
> provides a means to an end: working wireless and it isn't causing
> significant strain on the project in terms of development effort.
>
> Our end users are not always developers and I think removing this
> feature will hurt more than it will help.
>
>
As an end user, the main issue I have is that according to the manpage
it supports ndis 5.1
According to
http://en.wikipedia.org/wiki/Network_Driver_Interface_Specification this
is the version supported by
Windows XP , Server 2003
, Windows CE
 4.x, 5.0, 6.0

As you might guess most new devices wont be coming with drivers for XP,
so does this mean I wont be able to use drivers for a recent windows
version (my understanding is that it will but happy to learn differently)
If this is the case and there is no active development on it, a gradual
depreciation over the 10.x series is probably a good idea. If however
its likely to support current drivers/devices it does have a place (I've
used it once or twice in a pinch.)


Vince
^
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: [rfc] removing the NDISulator

[Adrian Chadd]

Hi,

The later driver model isn't supported by ndisulator. We'd have to
implement all the newer NDIS stuff for wifi and ethernet.

In the later NDIS layer the Microsoft Wireless Services implement a bunch
of stuff that used to be up to the driver. Ie, the driver just exposed an
ethernet "device" with some extra bits for wifi. Ie, the whole stack runs
in the driver. That has changed.




-adrian
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: [rfc] removing the NDISulator

[Thomas Mueller]

> > On 23 October 2013 13:10, claudiu vasadi  wrote:

> > Hi,

> > Still getting the "Cannot reset interface wlan0 - exit status 1" in
> > wifimgr but no crash yet. Will keep trying :D


> I have no idea about that. It's likely there's some net80211/iwn bug(s) but
> I don't use wifimgr so I don't know what it's doing.

> For that I'd bug the wifimgr people in PCBSD. they can always file bug
> reports with me :)

> Thanks,



> -adrian

I don't have wifimgr either, can't even install it until I get wifi set up.

Does wifimgr have more functionality than wpa_cli?

Why would some drivers not be ndisulatable/ndiswrappable?

Would that be because the resulting driver would fail, or because of the 
lack of .inf and .sys files in Windows driver?

Tom

___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: [rfc] removing the NDISulator

[John-Mark Gurney]

Adrian Chadd wrote this message on Wed, Oct 23, 2013 at 11:11 -0700:
> On 23 October 2013 11:09, Alfred Perlstein  wrote:
> 
> > Eh, having taken a stab at porting the bwl blob already, I would strongly
> >> oppose removing NDIS.  If you do that I will just stop using my netbook
> >> with a Broadcom part altogether as I wouldn't be able to use it to try to
> >> test bwl changes.  The NDIS thing is a bit hackish, but it is quite useful
> >> for a lot of folks.
> >>
> >>  I have to agree.  Deprecation != motivation.
> 
> 
> I can pull out examples of this not holding true:
> 
> * all the giant locking in drivers
> * all the giant locking in VFS
> 
> People did pop up and claim ownership of things they cared about. Some
> stuff died, some stuff didn't. There was enough of a motivation by us to
> kill giant off in these pathways so things could continue to evolve. We
> didn't leave the GIANT crutch in forever.

I'd say that locking a drive is a LOT easier than writing a driver
from scratch, esspecially if you don't have the specs..  This of course
coming from experience with both...

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: [rfc] removing the NDISulator

[Adrian Chadd]

And the link momentum is strong now. There's driver source.

Adrian
On Oct 23, 2013 2:41 PM, "John Baldwin"  wrote:

> On Wednesday, October 23, 2013 2:11:29 pm Adrian Chadd wrote:
> > On 23 October 2013 11:09, Alfred Perlstein  wrote:
> >
> >
> > > Eh, having taken a stab at porting the bwl blob already, I would
> strongly
> > >> oppose removing NDIS.  If you do that I will just stop using my
> netbook
> > >> with a Broadcom part altogether as I wouldn't be able to use it to
> try to
> > >> test bwl changes.  The NDIS thing is a bit hackish, but it is quite
> useful
> > >> for a lot of folks.
> > >>
> > >>  I have to agree.  Deprecation != motivation.
> >
> >
> > I can pull out examples of this not holding true:
> >
> > * all the giant locking in drivers
> > * all the giant locking in VFS
> >
> > People did pop up and claim ownership of things they cared about. Some
> > stuff died, some stuff didn't. There was enough of a motivation by us to
> > kill giant off in these pathways so things could continue to evolve. We
> > didn't leave the GIANT crutch in forever.
>
> Giant isn't dead yet. :)  (And I've done a lot of the de-Gianting FWIW.)
>
> I don't consider ndis in the same camp.  Often times there are vendors
> where
> datasheets, etc. are not obtainable, but a foo.sys + foo.inf is.
>
> --
> John Baldwin
>
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: [rfc] removing the NDISulator

[John Baldwin]

On Wednesday, October 23, 2013 2:11:29 pm Adrian Chadd wrote:
> On 23 October 2013 11:09, Alfred Perlstein  wrote:
> 
> 
> > Eh, having taken a stab at porting the bwl blob already, I would strongly
> >> oppose removing NDIS.  If you do that I will just stop using my netbook
> >> with a Broadcom part altogether as I wouldn't be able to use it to try to
> >> test bwl changes.  The NDIS thing is a bit hackish, but it is quite 
useful
> >> for a lot of folks.
> >>
> >>  I have to agree.  Deprecation != motivation.
> 
> 
> I can pull out examples of this not holding true:
> 
> * all the giant locking in drivers
> * all the giant locking in VFS
> 
> People did pop up and claim ownership of things they cared about. Some
> stuff died, some stuff didn't. There was enough of a motivation by us to
> kill giant off in these pathways so things could continue to evolve. We
> didn't leave the GIANT crutch in forever.

Giant isn't dead yet. :)  (And I've done a lot of the de-Gianting FWIW.)

I don't consider ndis in the same camp.  Often times there are vendors where
datasheets, etc. are not obtainable, but a foo.sys + foo.inf is.

-- 
John Baldwin
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: [rfc] removing the NDISulator

[Adrian Chadd]

Because the Linux stuff is mostly very GPL.

Adrian
On Oct 23, 2013 2:15 PM, "Alfred Perlstein"  wrote:

> On 10/23/13 11:11 AM, Adrian Chadd wrote:
>
>> On 23 October 2013 11:09, Alfred Perlstein  wrote:
>>
>>
>>  Eh, having taken a stab at porting the bwl blob already, I would strongly
>>>
 oppose removing NDIS.  If you do that I will just stop using my netbook
 with a Broadcom part altogether as I wouldn't be able to use it to try
 to
 test bwl changes.  The NDIS thing is a bit hackish, but it is quite
 useful
 for a lot of folks.

   I have to agree.  Deprecation != motivation.

>>>
>> I can pull out examples of this not holding true:
>>
>> * all the giant locking in drivers
>> * all the giant locking in VFS
>>
>> People did pop up and claim ownership of things they cared about. Some
>> stuff died, some stuff didn't. There was enough of a motivation by us to
>> kill giant off in these pathways so things could continue to evolve. We
>> didn't leave the GIANT crutch in forever.
>>
>>
>>  Sure, however those drivers and vfs systems were not sustainable and
> holding the kernel back.
>
> What part of the NDISulator actually holds the system back?  I'm saying
> that it seems as if it was conjecture rather than a need.  Is the
> NDISulator giant locked?
>
> Also why the interest in writing drivers so much?  Being able to leverage
> other platform drivers is pretty neat and saves us a ton of work.
>
> --
> Alfred Perlstein
>
>
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: [rfc] removing the NDISulator

[Alfred Perlstein]

On 10/23/13 7:23 AM, John Baldwin wrote:

On Monday, October 21, 2013 6:29:24 pm Adrian Chadd wrote:

The NDISulator is a crutch from a time when there wasn't _any_ real
alternative.

There are plenty of alternatives now. What's lacking is desire and
person-power. But the datasheets are there, or the vendor code has been
released, or there's linux/otherbsd drivers.

Leaving it in there is just delaying the inevitable - drivers need to be
fixed, ported, or reverse engineered.

This is going to upset users in the same way that eliminating any other
transition/sideways compatibility layer upsets users. But as I said, the
path forward is fixing up the lack of stable drivers, not simply supporting
some crutch.

If there are drivers that people absolutely need fixed then they should
stand up and say "hey, I really would like X to work better!" and then
follow it up with some encouraging incentives. Right now the NDISulator
lets people work _around_ this by having something that kind of works for
them but it doesn't improve our general driver / stack ecosystems.

Eh, having taken a stab at porting the bwl blob already, I would strongly
oppose removing NDIS.  If you do that I will just stop using my netbook
with a Broadcom part altogether as I wouldn't be able to use it to try to
test bwl changes.  The NDIS thing is a bit hackish, but it is quite useful
for a lot of folks.


I have to agree.  Deprecation != motivation.

--
Alfred Perlstein

___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: [rfc] removing the NDISulator

[Alfred Perlstein]

On 10/23/13 11:11 AM, Adrian Chadd wrote:

On 23 October 2013 11:09, Alfred Perlstein  wrote:



Eh, having taken a stab at porting the bwl blob already, I would strongly

oppose removing NDIS.  If you do that I will just stop using my netbook
with a Broadcom part altogether as I wouldn't be able to use it to try to
test bwl changes.  The NDIS thing is a bit hackish, but it is quite useful
for a lot of folks.

  I have to agree.  Deprecation != motivation.


I can pull out examples of this not holding true:

* all the giant locking in drivers
* all the giant locking in VFS

People did pop up and claim ownership of things they cared about. Some
stuff died, some stuff didn't. There was enough of a motivation by us to
kill giant off in these pathways so things could continue to evolve. We
didn't leave the GIANT crutch in forever.


Sure, however those drivers and vfs systems were not sustainable and 
holding the kernel back.


What part of the NDISulator actually holds the system back?  I'm saying 
that it seems as if it was conjecture rather than a need.  Is the 
NDISulator giant locked?


Also why the interest in writing drivers so much?  Being able to 
leverage other platform drivers is pretty neat and saves us a ton of work.


--
Alfred Perlstein

___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: [rfc] removing the NDISulator

[Adrian Chadd]

On 23 October 2013 11:09, Alfred Perlstein  wrote:


> Eh, having taken a stab at porting the bwl blob already, I would strongly
>> oppose removing NDIS.  If you do that I will just stop using my netbook
>> with a Broadcom part altogether as I wouldn't be able to use it to try to
>> test bwl changes.  The NDIS thing is a bit hackish, but it is quite useful
>> for a lot of folks.
>>
>>  I have to agree.  Deprecation != motivation.


I can pull out examples of this not holding true:

* all the giant locking in drivers
* all the giant locking in VFS

People did pop up and claim ownership of things they cared about. Some
stuff died, some stuff didn't. There was enough of a motivation by us to
kill giant off in these pathways so things could continue to evolve. We
didn't leave the GIANT crutch in forever.



-adrian
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: [rfc] removing the NDISulator

[Eitan Adler]

On Mon, Oct 21, 2013 at 6:29 PM, Adrian Chadd  wrote:
> If there are drivers that people absolutely need fixed then they should
> stand up and say "hey, I really would like X to work better!" and then
> follow it up with some encouraging incentives. Right now the NDISulator
> lets people work _around_ this by having something that kind of works for
> them but it doesn't improve our general driver / stack ecosystems.

I doubt most people prefer to use the ndisulator over a native driver.
However, many people don't have the skills, time, or money to provide
the incentives you are talking about.  At this point ndisulator
provides a means to an end: working wireless and it isn't causing
significant strain on the project in terms of development effort.

Our end users are not always developers and I think removing this
feature will hurt more than it will help.


-- 
Eitan Adler
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: [rfc] removing the NDISulator

[John Baldwin]

On Monday, October 21, 2013 6:29:24 pm Adrian Chadd wrote:
> The NDISulator is a crutch from a time when there wasn't _any_ real
> alternative.
> 
> There are plenty of alternatives now. What's lacking is desire and
> person-power. But the datasheets are there, or the vendor code has been
> released, or there's linux/otherbsd drivers.
> 
> Leaving it in there is just delaying the inevitable - drivers need to be
> fixed, ported, or reverse engineered.
> 
> This is going to upset users in the same way that eliminating any other
> transition/sideways compatibility layer upsets users. But as I said, the
> path forward is fixing up the lack of stable drivers, not simply supporting
> some crutch.
> 
> If there are drivers that people absolutely need fixed then they should
> stand up and say "hey, I really would like X to work better!" and then
> follow it up with some encouraging incentives. Right now the NDISulator
> lets people work _around_ this by having something that kind of works for
> them but it doesn't improve our general driver / stack ecosystems.

Eh, having taken a stab at porting the bwl blob already, I would strongly
oppose removing NDIS.  If you do that I will just stop using my netbook
with a Broadcom part altogether as I wouldn't be able to use it to try to
test bwl changes.  The NDIS thing is a bit hackish, but it is quite useful
for a lot of folks.

-- 
John Baldwin
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: [rfc] removing the NDISulator

[Thomas Mueller]

> The NDISulator is a crutch from a time when there wasn't _any_ real
> alternative.

> There are plenty of alternatives now. What's lacking is desire and
> person-power. But the datasheets are there, or the vendor code has been
> released, or there's linux/otherbsd drivers.
 
> Leaving it in there is just delaying the inevitable - drivers need to be
> fixed, ported, or reverse engineered.

> This is going to upset users in the same way that eliminating any other
> transition/sideways compatibility layer upsets users. But as I said, the
> path forward is fixing up the lack of stable drivers, not simply supporting
> some crutch.

> If there are drivers that people absolutely need fixed then they should
> stand up and say "hey, I really would like X to work better!" and then
> follow it up with some encouraging incentives. Right now the NDISulator
> lets people work _around_ this by having something that kind of works for
> them but it doesn't improve our general driver / stack ecosystems.



> -adrian

Sometimes a crutch is needed.

But it would be desirable to have a means for using a driver from Linux, NetBSD 
or OpenBSD.

Sometimes the FreeBSD driver is buggy, like re with Realtek 8111E on MSI Z77 
MPOWER motherboard.

I couldn't checkout FreeBSD 10-current source tree from 9.2 amd64 or 9.1-STABLE 
i386 USB stick, but was able to checkout and update the source tree to build 
FreeBSD 10-current (now 11-current and 10.0-BETA1) after updating my 
NetBSD-HEAD amd64 USB-stick installation and building subversion from pkgsrc.

I could checkout the ports tree too but would not be able to make fetch.

A driver might work with FreeBSD but fail temporarily in a later source 
revision due to a new bug.

So it's good to use FreeBSD native driver when possible but have ndis for 
fallback.

One problem with NDIS is that now it seems that running "unzip -l" on the 
Windows driver shows no .inf and .sys files.

One can then try from ReactOS or Wine, and even if the installation of Windows 
driver doesn't work, it might possibly yield .inf and .sys files.

I never tried that so am not making any bets.

Tom

___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: [rfc] removing the NDISulator

[Adrian Chadd]

The NDISulator is a crutch from a time when there wasn't _any_ real
alternative.

There are plenty of alternatives now. What's lacking is desire and
person-power. But the datasheets are there, or the vendor code has been
released, or there's linux/otherbsd drivers.

Leaving it in there is just delaying the inevitable - drivers need to be
fixed, ported, or reverse engineered.

This is going to upset users in the same way that eliminating any other
transition/sideways compatibility layer upsets users. But as I said, the
path forward is fixing up the lack of stable drivers, not simply supporting
some crutch.

If there are drivers that people absolutely need fixed then they should
stand up and say "hey, I really would like X to work better!" and then
follow it up with some encouraging incentives. Right now the NDISulator
lets people work _around_ this by having something that kind of works for
them but it doesn't improve our general driver / stack ecosystems.



-adrian


On 21 October 2013 14:46, Julian H. Stacey  wrote:

> "Andrey V. Elsukov"  wrote:
>
> > I'm agree. While there are still some devices without native drivers,
> > but that work via NDISulator, we should keep it.
>
> Yes, best keep it while it helps some people.
>
>
> Adrian Chadd  wrote:
>
> > It's honestly about time that these were updated, fixed and/or ported to
> > FreeBSD.
> >
> > So, I'm still going forward with the plan. I won't be killing it during
> the
> > 10 lifecycle.
>
> If ndis is removed while it works, that would be bad for users,
> some of whom won't even be on lists, but use ndis as their lifeboat.
>
> If ndis is later labeled as abandoned & if maintenance ceases, & if it
> then breaks, only then will pressure increase on others to step
> forward & help fix things; if a wait then sees no one stepping forward,
> surely only then would removal seem most appropriate ?
>
> Cheers,
> Julian
> --
> Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich
> http://berklix.com
>  Interleave replies below like a play script.  Indent old text with "> ".
>  Send plain text, not quoted-printable, HTML, base64, or
> multipart/alternative.
>
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: [rfc] removing the NDISulator

[Julian H. Stacey]

"Andrey V. Elsukov"  wrote:

> I'm agree. While there are still some devices without native drivers,
> but that work via NDISulator, we should keep it.

Yes, best keep it while it helps some people.


Adrian Chadd  wrote:

> It's honestly about time that these were updated, fixed and/or ported to
> FreeBSD.
> 
> So, I'm still going forward with the plan. I won't be killing it during the
> 10 lifecycle.

If ndis is removed while it works, that would be bad for users,
some of whom won't even be on lists, but use ndis as their lifeboat.

If ndis is later labeled as abandoned & if maintenance ceases, & if it
then breaks, only then will pressure increase on others to step
forward & help fix things; if a wait then sees no one stepping forward,
surely only then would removal seem most appropriate ?

Cheers,
Julian
-- 
Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com
 Interleave replies below like a play script.  Indent old text with "> ".
 Send plain text, not quoted-printable, HTML, base64, or multipart/alternative.
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: [rfc] removing the NDISulator

[Adrian Chadd]

On 21 October 2013 12:59, Andrey V. Elsukov  wrote:

> On 19.10.2013 10:01, Thomas Mueller wrote:
> > I too would like to see more effort writing new Ethernet and wifi
> > drivers and porting from other operating systems.
> >
> > But I would like to keep the NDISulator/NDISwrapper as a fallback.
> >
> > There are still wifi adapters, Ethernet too, where there is no
> > FreeBSD driver (AR9271 for instance), or the FreeBSD driver is
> > buggy.
>
> I'm agree. While there are still some devices without native drivers,
> but that work via NDISulator, we should keep it.
>

It's honestly about time that these were updated, fixed and/or ported to
FreeBSD.

So, I'm still going forward with the plan. I won't be killing it during the
10 lifecycle.




-adrian
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: [rfc] removing the NDISulator

[Andrey V. Elsukov]

On 19.10.2013 10:01, Thomas Mueller wrote:
> I too would like to see more effort writing new Ethernet and wifi
> drivers and porting from other operating systems.
> 
> But I would like to keep the NDISulator/NDISwrapper as a fallback.
> 
> There are still wifi adapters, Ethernet too, where there is no
> FreeBSD driver (AR9271 for instance), or the FreeBSD driver is
> buggy.

I'm agree. While there are still some devices without native drivers,
but that work via NDISulator, we should keep it.

-- 
WBR, Andrey V. Elsukov
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: [rfc] removing the NDISulator

[Matthias Apitz]

El día Friday, October 18, 2013 a las 02:19:42PM -0700, Adrian Chadd escribió:

> I'd really like to see bwi/bwn maintained and have support added for the
> later hardware.

Hi Adrian,

$ pciconf -vl 
ndis0@pci0:1:0:0:   class=0x028000 card=0xe01b105b chip=0x431514e4 rev=0x01 
hdr=0x00
vendor = 'Broadcom Corporation'
device = 'BCM4312 802.11b/g LP-PHY'
class  = network

I'm using NDIS as well in r250588. Is bwi/bwn the point to start to look
into for this chip? Thanks

matthias
-- 
Matthias Apitz   |  /"\ ASCII Ribbon Campaign: www.asciiribbon.org
E-mail: g...@unixarea.de |  \ / - No HTML/RTF in E-mail
WWW: http://www.unixarea.de/ |   X  - No proprietary attachments
phone: +49-170-4527211   |  / \ - Respect for open standards
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: [rfc] removing the NDISulator

[m]

On 01:51 19-Oct 2013 Adrian Chadd wrote:
> bwn(4) requires a lot more than just an additional PCI ID.
> 
> The driver is somewhat architected for all the different RF and PHY modules
> that plug into the internal bus (the whole SIBA thing) but it does sorely
> need updating.
>

In brcsmac (driver that supports 4313 and whole bunch of new chips) they
have replaced SIBA with AMBA-like bus[1]. Although, README says, that
they don't use anything AMBA-specific. Probably SIBA can be hacked up at
least for PCI case.

Actually, I've started playing with Linux version of the driver[2], it's
opensource and dual-licensed, but code seem to me very tangled. (Code of
the bus part is GPL-only)

Can you recommend any papers about wireless drivers in general?
Particularly, I'm interested in working with PHY/ratetables.

[1] https://github.com/torvalds/linux/blob/master/drivers/bcma/README
[2]
https://github.com/torvalds/linux/tree/master/drivers/net/wireless/brcm80211/brcmsmac
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: [rfc] removing the NDISulator

[Thomas Mueller]

> I'd like to remove the NDISulator. I've had many requests to update it to
> the latest NDIS version and support more of the 64 bit wifi drivers. But,
> to be perfectly honest, I have no desire to keep hacking at this. The world
> has changed quite a bit - we can port/reimplement drivers from Linux and
> other BSDs.

> So I plan on deorbiting it - I'll mark it deprecated during 11-HEAD and
> target to have it removed by 11.0-RELEASE.

> I'd rather see more of an effort writing new drivers and porting drivers
> from other operating systems.

> Thanks,



> -adrian

I too would like to see more effort writing new Ethernet and wifi drivers and 
porting from other operating systems.

But I would like to keep the NDISulator/NDISwrapper as a fallback.

There are still wifi adapters, Ethernet too, where there is no FreeBSD driver 
(AR9271 for instance), or the FreeBSD driver is buggy.

Realtek 8111E on MSI Z77 MPOWER motherboard is one case in point: good with 
NetBSD-current and Linux but not OpenBSD 5.3 LiveUSB or FreeBSD. 

I see FreeBSD 10.0-to-be has a bigger selection of drivers than 9.2.

I don't see improvements so far in 11-HEAD over 10.0-BETA1, but that's because 
11-HEAD is at a very early stage.

Regarding NDISulator, I see that it seems nowadays that many MS-Windows driver 
packages, when unzipped, have setup.exe, some .ini files, some .cab and .hdr 
files but no .inf and .sys files necessary for the NDISulator.

Presumably these files are created/unpacked when the driver is installed in 
MS-Windows.

Tom

___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: [rfc] removing the NDISulator

[Adrian Chadd]

I don't know how many times i can say "it needs a maintainer" and "it needs
updating."

So yeah, it needs (a) a maintainer, (b) updating.



-adrian



On 18 October 2013 15:47, Alfred Perlstein  wrote:

> On 10/18/13 2:04 PM, Nathan Whitehorn wrote:
>
>> On 10/18/13 16:01, Steve Kargl wrote:
>>
>>> On Fri, Oct 18, 2013 at 08:53:54PM +, Steve Wills wrote:
>>>
 I would love to have a native driver for this:

 none2@pci0:2:0:0:
  class=0x028000 card=0x00101028 chip=0x472714e4 rev=0x01 hdr=0x00
  vendor = 'Broadcom Corporation'
  device = 'BCM4313 802.11b/g/n Wireless LAN Controller'
  class  = network

 Are there docs or other drivers available that we could look at?

  Please, don't top post as it loses context.
>>>
>>> http://www.broadcom.com/**support/802.11/linux_sta.php
>>>
>>>
>> Have you looked at bwn(4)? It might just need an additional PCI ID.
>> -Nathan
>>
>>  I'm having no love with if_bwn.  Any tips on making it work better?
>
> I have -current as of ~2 weeks ago.
>
> --
> Alfred Perlstein
>
>
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: [rfc] removing the NDISulator

[Alfred Perlstein]

On 10/18/13 2:04 PM, Nathan Whitehorn wrote:

On 10/18/13 16:01, Steve Kargl wrote:

On Fri, Oct 18, 2013 at 08:53:54PM +, Steve Wills wrote:

I would love to have a native driver for this:

none2@pci0:2:0:0:
 class=0x028000 card=0x00101028 chip=0x472714e4 rev=0x01 hdr=0x00
 vendor = 'Broadcom Corporation'
 device = 'BCM4313 802.11b/g/n Wireless LAN Controller'
 class  = network

Are there docs or other drivers available that we could look at?


Please, don't top post as it loses context.

http://www.broadcom.com/support/802.11/linux_sta.php



Have you looked at bwn(4)? It might just need an additional PCI ID.
-Nathan


I'm having no love with if_bwn.  Any tips on making it work better?

I have -current as of ~2 weeks ago.

--
Alfred Perlstein

___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: [rfc] removing the NDISulator

[Adrian Chadd]

bwn(4) requires a lot more than just an additional PCI ID.

The driver is somewhat architected for all the different RF and PHY modules
that plug into the internal bus (the whole SIBA thing) but it does sorely
need updating.

Thanks,


-adrian



On 18 October 2013 14:04, Nathan Whitehorn  wrote:

> On 10/18/13 16:01, Steve Kargl wrote:
>
>> On Fri, Oct 18, 2013 at 08:53:54PM +, Steve Wills wrote:
>>
>>> I would love to have a native driver for this:
>>>
>>> none2@pci0:2:0:0:
>>>  class=0x028000 card=0x00101028 chip=0x472714e4 rev=0x01 hdr=0x00
>>>  vendor = 'Broadcom Corporation'
>>>  device = 'BCM4313 802.11b/g/n Wireless LAN Controller'
>>>  class  = network
>>>
>>> Are there docs or other drivers available that we could look at?
>>>
>>>  Please, don't top post as it loses context.
>>
>> http://www.broadcom.com/**support/802.11/linux_sta.php
>>
>>
> Have you looked at bwn(4)? It might just need an additional PCI ID.
> -Nathan
>
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: [rfc] removing the NDISulator

[Nathan Whitehorn]

On 10/18/13 16:01, Steve Kargl wrote:

On Fri, Oct 18, 2013 at 08:53:54PM +, Steve Wills wrote:

I would love to have a native driver for this:

none2@pci0:2:0:0:
 class=0x028000 card=0x00101028 chip=0x472714e4 rev=0x01 hdr=0x00
 vendor = 'Broadcom Corporation'
 device = 'BCM4313 802.11b/g/n Wireless LAN Controller'
 class  = network

Are there docs or other drivers available that we could look at?


Please, don't top post as it loses context.

http://www.broadcom.com/support/802.11/linux_sta.php



Have you looked at bwn(4)? It might just need an additional PCI ID.
-Nathan
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: [rfc] removing the NDISulator

[Adrian Chadd]

Hi,


On 18 October 2013 13:53, Steve Wills  wrote:

> I would love to have a native driver for this:
>
> none2@pci0:2:0:0:   class=0x028000 card=0x00101028 chip=0x472714e4
> rev=0x01 hdr=0x00
> vendor = 'Broadcom Corporation'
> device = 'BCM4313 802.11b/g/n Wireless LAN Controller'
> class  = network
>
> Are there docs or other drivers available that we could look at?
>

There's multiple broadcom drivers in/for the linux kernel:

* b43, the reverse engineered one, from the community
* brcmsmac - the softmac broadcom driver, from broadcom
* the STA only binary driver from broadcom, closed source, not in the
kernel.

I'd really like to see bwi/bwn maintained and have support added for the
later hardware.

Thanks,



-adrian
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: [rfc] removing the NDISulator

[Steve Kargl]

On Fri, Oct 18, 2013 at 08:53:54PM +, Steve Wills wrote:
> I would love to have a native driver for this:
> 
> none2@pci0:2:0:0: 
> class=0x028000 card=0x00101028 chip=0x472714e4 rev=0x01 hdr=0x00
> vendor = 'Broadcom Corporation'
> device = 'BCM4313 802.11b/g/n Wireless LAN Controller'
> class  = network
> 
> Are there docs or other drivers available that we could look at?
> 

Please, don't top post as it loses context.

http://www.broadcom.com/support/802.11/linux_sta.php

-- 
Steve
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: [rfc] removing the NDISulator

[Steve Wills]

I would love to have a native driver for this:

none2@pci0:2:0:0:   class=0x028000 card=0x00101028 chip=0x472714e4 rev=0x01 
hdr=0x00
vendor = 'Broadcom Corporation'
device = 'BCM4313 802.11b/g/n Wireless LAN Controller'
class  = network

Are there docs or other drivers available that we could look at?

Steve

On Fri, Oct 18, 2013 at 11:00:20AM -0700, Adrian Chadd wrote:
> Hi all,
> 
> I'd like to remove the NDISulator. I've had many requests to update it to
> the latest NDIS version and support more of the 64 bit wifi drivers. But,
> to be perfectly honest, I have no desire to keep hacking at this. The world
> has changed quite a bit - we can port/reimplement drivers from Linux and
> other BSDs.
> 
> So I plan on deorbiting it - I'll mark it deprecated during 11-HEAD and
> target to have it removed by 11.0-RELEASE.
> 
> I'd rather see more of an effort writing new drivers and porting drivers
> from other operating systems.
> 
> Thanks,
> 
> 
> 
> -adrian
> ___
> freebsd-curr...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"