Re: [rfc] removing the NDISulator

2013-10-25 Thread 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 path-to-whatever-I called that file ?

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

2013-10-24 Thread 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

2013-10-24 Thread 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

2013-10-23 Thread 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

2013-10-23 Thread Eitan Adler
On Mon, Oct 21, 2013 at 6:29 PM, Adrian Chadd adr...@freebsd.org 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

2013-10-23 Thread Adrian Chadd
On 23 October 2013 11:09, Alfred Perlstein bri...@mu.org 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

2013-10-23 Thread Alfred Perlstein

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

On 23 October 2013 11:09, Alfred Perlstein bri...@mu.org 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

2013-10-23 Thread 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

2013-10-23 Thread Adrian Chadd
Because the Linux stuff is mostly very GPL.

Adrian
On Oct 23, 2013 2:15 PM, Alfred Perlstein bri...@mu.org wrote:

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

 On 23 October 2013 11:09, Alfred Perlstein bri...@mu.org 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

2013-10-23 Thread John Baldwin
On Wednesday, October 23, 2013 2:11:29 pm Adrian Chadd wrote:
 On 23 October 2013 11:09, Alfred Perlstein bri...@mu.org 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

2013-10-23 Thread Adrian Chadd
And the link momentum is strong now. There's driver source.

Adrian
On Oct 23, 2013 2:41 PM, John Baldwin j...@freebsd.org wrote:

 On Wednesday, October 23, 2013 2:11:29 pm Adrian Chadd wrote:
  On 23 October 2013 11:09, Alfred Perlstein bri...@mu.org 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

2013-10-23 Thread Thomas Mueller
  On 23 October 2013 13:10, claudiu vasadi claudiu.vas...@gmail.com 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

2013-10-23 Thread Vincent Hoffman
On 23/10/2013 18:35, Eitan Adler wrote:
 On Mon, Oct 21, 2013 at 6:29 PM, Adrian Chadd adr...@freebsd.org 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 http://en.wikipedia.org/wiki/Windows_XP, Server 2003
http://en.wikipedia.org/wiki/Windows_Server_2003, Windows CE
http://en.wikipedia.org/wiki/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

2013-10-22 Thread 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

2013-10-21 Thread Adrian Chadd
On 21 October 2013 12:59, Andrey V. Elsukov bu7c...@yandex.ru 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

2013-10-21 Thread Julian H. Stacey
Andrey V. Elsukov bu7c...@yandex.ru 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 adr...@freebsd.org 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

2013-10-21 Thread 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 j...@berklix.com wrote:

 Andrey V. Elsukov bu7c...@yandex.ru 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 adr...@freebsd.org 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

2013-10-19 Thread 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

2013-10-19 Thread 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

2013-10-19 Thread 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

2013-10-18 Thread 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


Re: [rfc] removing the NDISulator

2013-10-18 Thread 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

2013-10-18 Thread Adrian Chadd
Hi,


On 18 October 2013 13:53, Steve Wills swi...@freebsd.org 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

2013-10-18 Thread 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

2013-10-18 Thread 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 nwhiteh...@freebsd.org 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.phphttp://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

2013-10-18 Thread 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

2013-10-18 Thread 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 bri...@mu.org 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.phphttp://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