RE: ndis0 no link on 6.3-RELEASE
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Glen Barber > Sent: Thursday, March 13, 2008 6:56 PM > To: freebsd-net@freebsd.org; [EMAIL PROTECTED] > Subject: ndis0 no link on 6.3-RELEASE > > > Hello everyone. > > First off, sorry for the double post, but I'm not 100% certain at > where this > post belongs. > > I've found via Google many problems with ndis0 and failure to > find a link in > 6.3-RELEASE, without resolution. So here's my setup. > > I'm using a Broadcom 4318 chipset, with drivers created from > ndisgen. If you > need more specific information on the drivers, I'll be more than happy to > provide information, however I believe it to be irrelevant at > this moment, as > I have used more than one driver version, with the same results. > > In 6.3-RC1 and below (tested in 6.2-RELEASE, and all -STABLE releases in > between), my ndis0 adapter works as exptected, using WPA and > DHCP. I can't > pinpoint exaclty what changed (I've check in /usr/src/UPDATING, > as it seemed > to be most relevant), with no avail to finding anything regarding > either wpa > or dhclient. > > Since an upgrade to 6.3-RELEASE (both, via csup and a fresh > install off of > cd), I generate my ndis module, create an /etc/wpa_supplicant.conf, > leaving /etc/dhclient as default, and am prompted with: > ndis0: no link.. giving up > > Upon 'kldunload bcmwl5.ko; kldload bcmwl5.ko', my ndis0 card > looses all WPA > capabilities. > > What seems to me to be the interesting part is this: > If I 'csup' to 6.3-RELEASE from -RC1, and build a kernel, the > problem does not > occur -- as long as I do not 'buildworld'. However, once I 'buildworld; > installworld', I am faced with the same problems as if I had installed > 6.3-RELEASE from cd. > > I would really like to figure out what is causing this (both for > myself, and > the other affected ndis0 victims), but I'm not sure where to look -- > dhclient, wpa_supplicant or ndis itself. Any other information I could > provide, please let me know. > Hi Glen, I just setup my laptop with a wireless card a couple weeks ago and FreeBSD 6.3-RELEASE. (it's an older Toshiba) I went through a total of 5 different wireless cards before I found one that I was able to get working ndis drivers from ndisgen. Fortunately there's a used computer place near here (freegeek.org) that had a box of pcmcia wireless cards of all different makes and models, which kindly allowed me to plunk down my laptop (which dual-boots between Windows 98 and FreeBSD) and they have wireless. So I would pick a card out of their bin, boot into Windows, download the Windows driver, make sure the card worked under Windows, then boot into FreeBSD and mount the Windows partition, copy over the Windows driver and inf file to the FreeBSD side, run ndisgen and then try loading the driver. With some cards, the driver wouldn't even activate the card. With other cards, the driver would allow me to list the wireless nodes then panic the system when I tried associating. The card that did work was a Realtek-based card. And, it did not work with the most current Windows drivers from the Realtek website, it worked with the Windows drivers that were from a couple years ago. (I found this out quite by accident) Fortunately, they DID also have a number of the Wavelan cards - these are supported natively with the wi0 driver - that worked out of the box. Those cards are only 802.11b though so I kept at it with ndisgen and the newer cards. The interesting thing is that the original wireless card I had in the Toshiba - a Texas Instruments-based chipset model - never really quite worked properly in the Toshiba under Windows. I put it into a different laptop I owned - a Thinkpad, and it worked great in that. Unfortunately, in your case, nothing has changed with ndisgen since 2006 (see http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/ndiscvt/ ) so it's not that, it's something else in the system that changed. Start with the basics. Copy your bcmwl5.ko into /boot/modules then in loader.conf put bcmw15_load="YES" and reboot the system, check dmesg, and see if it's even loading Next put in /etc/rc.conf "ifconfig_ndis0="inet 192.168.1.1 ssid myssid" and see if it even comes up at all and you can ping out (obviously you will have to temporairly turn off wpa on your wireless node, set the correct ssid, and set the correct IP address to hard-code an IP address) If that doesen't work, regen the bcmw15.ko file using the "old" method: # cp foo.sys foo.inf /sys/modules/if_ndis # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i foo.inf -s foo.sys -o ndis_driver_data.h # make; make load You need to isolate the problem to see if the driver is simply just not working at all under 6.3, or if it is working, but it's a scripting or turnup out of sequence error. And you need to see if wpa has anything to do
Re: ndis0 no link on 6.3-RELEASE
Ted Mittelstaedt said: > > I just setup my laptop with a wireless card a couple weeks > ago and FreeBSD 6.3-RELEASE. (it's an older Toshiba) > > I went through a total of 5 different wireless cards before > I found one that I was able to get working ndis drivers from > ndisgen. Fortunately there's a used computer place near here > (freegeek.org) that had a box of pcmcia wireless cards of all > different makes and models, which kindly allowed me to plunk > down my laptop (which dual-boots between Windows 98 and FreeBSD) > and they have wireless. So I would pick a card out of their bin, > boot into Windows, download the Windows driver, make sure the > card worked under Windows, then boot into FreeBSD and mount > the Windows partition, copy over the Windows driver and inf > file to the FreeBSD side, run ndisgen and then try loading the > driver. > > With some cards, the driver wouldn't even activate the card. > With other cards, the driver would allow me to list the wireless > nodes then panic the system when I tried associating. > > The card that did work was a Realtek-based card. And, it did > not work with the most current Windows drivers from the Realtek > website, it worked with the Windows drivers that were from a couple > years ago. (I found this out quite by accident) > > Fortunately, they DID also have a number of the Wavelan > cards - these are supported natively with the wi0 driver - > that worked out of the box. Those cards are only 802.11b > though so I kept at it with ndisgen and the newer cards. > > The interesting thing is that the original wireless card I > had in the Toshiba - a Texas Instruments-based chipset model - > never really quite worked properly in the Toshiba under Windows. > I put it into a different laptop I owned - a Thinkpad, and > it worked great in that. > > Unfortunately, in your case, nothing has changed with ndisgen > since 2006 (see http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/ndiscvt/ ) > so it's not that, it's something else in the system that changed. > > Start with the basics. Copy your bcmwl5.ko into /boot/modules > then in loader.conf put bcmw15_load="YES" and reboot the system, > check dmesg, and see if it's even loading > > Next put in /etc/rc.conf "ifconfig_ndis0="inet 192.168.1.1 ssid myssid" > and see if it even comes up at all and you can ping out (obviously > you will have to temporairly turn off wpa on your wireless node, > set the correct ssid, and set the correct IP address to hard-code an > IP address) > > If that doesen't work, regen the bcmw15.ko file using the "old" > method: > > # cp foo.sys foo.inf /sys/modules/if_ndis > # cd /sys/modules/ndis > # make; make load > # cd /sys/modules/if_ndis > # ndiscvt -i foo.inf -s foo.sys -o ndis_driver_data.h > # make; make load > > You need to isolate the problem to see if the driver is simply > just not working at all under 6.3, or if it is working, but it's > a scripting or turnup out of sequence error. And you need to > see if wpa has anything to do with it. > Hi Ted. Thanks for the reply. Unfortunately, until I either get time to resize my hard disk and add a separate freebsd installation, or I figure out how to undo a buildworld, looks like I'm stuck. It's my school laptop, so I kind of need to get work done. ;) (I am able to run a 6.3-RELEASE kernel, but the 'world' is 6.3-RC1.) Regarding older drivers: Yes, I had this problem with my current chipset in 6.2-RELEASE. This is why I was so surprised I had problems with 6.3-RELEASE. Either way, I appreciate your response. Cheers. -- Glen Barber http://www.dev-urandom.com/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: TCP options order changed in FreeBSD 7, incompatible with some routers
On 3/12/08, Andre Oppermann <[EMAIL PROTECTED]> wrote: > > We've already fixed two issues. The first changes the order of the TCP > options > and is in this change: > > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_var.h.diff?r1=1.160;r2=1.161 > > It is to solve a problem observed by ISC that sounds very much like what > you > describe. This fixed the issue in this case. Since this patch just has the effect of moving sackOK after the timestamps, it won't fix the problem that we were seeing, because it was occurring only in the absence of timestamps. > The second changes the alignment padding from NOP to 0x00. Whether this > was > a contributing factor to the reported problem is not clear. There hasn't > (yet) > been any specific test case for it. It was fixed because the RFC > specifies 0x00 > to be used for padding and nothing else. > > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_output.c.diff?r1=1.145;r2=1.146 This looks promising. I didn't realize that the 0x01 padding was wrong since I didn't read the spec :) > It would be very helpful if you could apply these two patches after each > other > to your 7.0 test server and find out together with the affected user(s) > which > of these fixes the issue. If you can please try to test each one with and > w/o > the routers firewall enabled. It is interesting to know whether the NAT > or > firewalling part of the router chokes on it. I've applied the two patches and reversed mine (side note -- sadly, this is a production server, not a test server) . I'll let you know shortly whether we're still having problems, and I'll also try get the router info for you. -coda ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Frequent pauses with Linux-based router
I have noticed that with a Linux-based Netgear DG834G (DSL modem) frequent pauses (example[1]) between external systems and 7-STABLE (March 14th). At first, I thought it was ipfilter or ipnat, but I took those out of the picture by activating telnet on the router and connecting directly to it. Even running "ls /usr/sbin" on the router would pause occasionally. I did not (or did not recall) have these problems with 6-STABLE (post 6.2). I switched out the NIC (FA-311 (sis) to a FA-310 (dc)), cable and tried different ports on the modem by which to connect. I also tried disabling all RFC sysctl's and SACK. Nothing helped. Finally, I brought out an old DSL modem (SpeedStream 5660). This fixed the issue. I think this maybe a specific issue between Linux (2.4.17_mvl21-malta-mips_fp_le) and FreeBSD 7. Is there anything else I may test to see what is happening? Sean 1. http://www.farley.org/freebsd/tmp/DSL/dsl-dmp.txt (telnet session between gateway and DSL modem) -- [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/121274: [panic] Panic in ether_input() with different NIC's.
Synopsis: [panic] Panic in ether_input() with different NIC's. State-Changed-From-To: feedback->open State-Changed-By: scf State-Changed-When: Sun Mar 16 15:42:57 CDT 2008 State-Changed-Why: As this looks like an issue between ipnat and gif, assign PR to darrenr for analysis. Responsible-Changed-From-To: freebsd-net->darrenr Responsible-Changed-By: scf Responsible-Changed-When: Sun Mar 16 15:42:57 CDT 2008 Responsible-Changed-Why: As this looks like an issue between ipnat and gif, assign PR to darrenr for analysis. http://www.freebsd.org/cgi/query-pr.cgi?pr=121274 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VLAN trunking and fragmentation
On Fri, Mar 14, 2008 at 04:37:36PM +0100, Giulio Ferro wrote: > Pyun YongHyeon wrote: > >This hardware really make me crazy. There had been many attempts to > >fix checksum offload related issues. But it seems that several users > >still suffer from bad checksum or VLAN issues. So I guess the root > >cause of hardware bug was not yet known. This means that previous > >patch to work around hardware bug is not complete. > > > >Hmm, I'm not sure but it could be related with padding. What makes > >me wonder is why the first packet of fragmented packet does not > >show up on destination host. I guess the second packet of fragmented > >packet may be composed of single mbuf. From these information I > >will experiment possible combination of work around in next week. > >I'll let you know when I have a code. > > > > > Great! Thanks for the good job. > Please try latest attempt to fix re(4) issues. http://people.freebsd.org/~yongari/re/if_re.c http://people.freebsd.org/~yongari/re/if_rlreg.h This one is attempt to fix the following bug reports on re(4). - VLAN tagging does not work on multi-fragmented frames. - Non-working/instability on re(4) hardwares that uses MSI. - Unconditional VLAN tag stripping without respect to ifconfig configuration. - ENOBUFS on transmitting UDP frames under heavy network loads. - DAC does not work. This one removed previous checksum offload hack for checksum offload on PCIe hardwares so I'm not sure checksum offload still work on PCIe hardwares. Please test and let me know how it goes. Also make sure you have all hardware features enabled.(checksum offload, TSO, VLAN hardware tagging etc). -- Regards, Pyun YongHyeon ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: TCP options order changed in FreeBSD 7, incompatible with some routers
On Fri, 14 Mar 2008, Bjoern A. Zeeb wrote: But I think the "good" case should look like it did before, per POLA. Ok, I am only printing it in case bad padding happens or one gave -v. The new patch is here: http://sources.zabbadoz.net/freebsd/patchset/20080314-01-tcpdump-print-tcp-option-padding.diff -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT I still think the non-bad case should look exactly as it did before, no matter what set of options was selected. :) I have not heard back from the tcpdump person that I contacted. :( -Mike ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: TCP options order changed in FreeBSD 7, incompatible with some routers
On Mon, 17 Mar 2008, Mike Silbersack wrote: On Fri, 14 Mar 2008, Bjoern A. Zeeb wrote: But I think the "good" case should look like it did before, per POLA. Ok, I am only printing it in case bad padding happens or one gave -v. The new patch is here: http://sources.zabbadoz.net/freebsd/patchset/20080314-01-tcpdump-print-tcp-option-padding.diff -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT I still think the non-bad case should look exactly as it did before, no matter what set of options was selected. :) I have not heard back from the tcpdump person that I contacted. :( Well I'd still like to be able to somehow see the padding if there is any without having to look at the hex output of each packet. But it's faily easy to get the behaviour you are requesting by simply removing the vflag now. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
