Newb needs help with netware (ncp)
I am trying to get my freebsd machine to mount a netware volume. The netware version is 6.5 running pure TCP. No IPX running on server. When I try mount_nwfs -A 204.111.42.194 /serv:admin/apps /mnt/serv I get an error message which states: mount_nwfs: mount error: /mnt/serv: syserr = No such file or directory I have created a directory named serv under the mnt directory. My fstab has the following line: /serv:admin /mnt/serv nwfsro,noauto 0 0 I have rebuilt my kernel with NCP added by using the following lines options IPX #IPX/SPX communications protocols options NCP #NetWare Core protocol options ETHER_II# enable Ethernet_II frame options ETHER_8023 # enable Ethernet_802.3 (Novell) frame options ETHER_8022 # enable Ethernet_802.2 frame options ETHER_SNAP I have researched this error until I have hit a dead end. This is my last hope for help. Thanks for any thoughts. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dhclient conflict between /sbin/devd and /etc/rc.d/netif ?
On Mon, Feb 11, 2008 at 06:51:58PM +1100, Robert Jenssen wrote:
> Hi Brooks and all,
>
> On Mon, 11 Feb 2008 12:06:26 pm you wrote:
> > On Mon, Feb 11, 2008 at 11:37:21AM +1100, Robert Jenssen wrote:
> > > Hi,
> > > Every so often I have trouble connecting rt2560 based PCI wireless
> > > network
> > > card to my wireless router/access point. Typically I get:
> > >
> > > # sudo /etc/rc.d/netif restart ral0
> > > Starting wpa_supplicant.
> > > ral0: no link .. giving up
> > > ral0: flags=8843 metric 0 mtu 1500
> > > ether 00:11:50:63:cd:47
> > > media: IEEE 802.11 Wireless Ethernet autoselect (DS/1Mbps)
> > > status: no carrier
> > >
> > > Even though there seems to be plenty of signal power:
> > >
> > > # sudo ifconfig ral0 list scan
> > > SSIDBSSID CHAN RATE S:N INT CAPS
> > > xxx... 00:xx:xx:xx:xx:xx 10 54M -74:-95 100 EPS WPA
> > >
> > > Recently I noticed that sometimes, after the above "netif restart" fails,
> the
> > > ral0 interface "automagically" comes up anyway. Then dhclient is owned
> > > by /sbin/devd. The default devd.conf starts dhclient for both ethernet
> > > and
> > > PCI-cardbus devices. Is it a good idea for both /sbin/devd
> > > and /etc/rc.d/netif to start a dhclient on ral0 at about the same time?
>
> In the "magical" case above what I think is happening is that the dhclient
> startup from /etc/rc.d/netif called by rc fails. Later /etc/rc.d/netif is
> called again from /etc/pccard_ether:pccard_ether_start() by /sbin/devd. That
> call succeeds.
As long as the interface is in the "up" state, /etc/pccard_ether will ignore
the interface. I'm fairly sure we don't configure interfaces twice, though
it's probably worth verifying that that's the case.
> The rc system uses rcorder to determine the order in which to run the rc
> scripts. On my system rcorder shows devd fairly early in the list. The
> devd.conf file calls a number of rc scripts. So far as I can see /sbin/devd
> doesn't check that these are called in the order listed by rcorder. Is this a
> problem?
Not generally, though it's vaguely possible there are still problems around.
The general idea is that all scripts devd should always be safe to call.
> I have disabled devd (set the moused port explicitly in rc.conf) and done
> some
> simple tests on /usr/src/sbin/dhclient.c. In particular, at line 365 main()
> allows a hard-coded maximum of 10 seconds for the call to
> interface_link_status() to succeed. I changed this to 20 seconds with a print
> out and ran /etc/rc.d/netif restart a few times with rc_debug="YES". The
> results were
> 15 15 5 5 5 5 5 15 15 5 5 5 5 5 21(timed out!) 5 5 and 5 seconds. Presumably
> the (10n+5) seconds is a magic number inside my wireless card or router. I'm
> going to set the hardcoded value to 25 seconds. Would it be possible for you
> to commit a similar change?
Sorry, no chance. It's too long for most people already.
> ("diff -C 5" to show the sleep()s!). Rather than dhclient.c timing 10 seconds
> and calling exit(), as shown above, shouldn't the dhclient.conf "timeout"
> configuration item cover this situation? I see that PR bin/98577 wants this
> hardcoded timeout reduced or made adjustable via dhclient.conf.
Some sort of link-timeout parameter might be acceptable as a new configuration
option.
-- Brooks
P.S. Your interface appears to be getting an address. Don't you have anything
better to worry about? :-)
pgpilMBqgxSt8.pgp
Description: PGP signature
Re: dhclient conflict between /sbin/devd and /etc/rc.d/netif ?
On Mon, Feb 11, 2008 at 01:23:57PM +1100, Robert Jenssen wrote: > Hi, > > Thanks for the prompt reply. By "owned", I meant that "ps -ajx" > shows /sbin/devd as the process group leader. For example, at the moment on > my system: > > [root etc]ps -axj | grep devd > root5727 1 5727 57270 Is??0:00.00 /sbin/devd > [root etc]ps -axj | grep dhclient > root6373 1 5727 57270 I ??0:00.00 dhclient: ral0 > _dhcp 6395 1 6395 63950 Ss??0:00.09 dhclient: ral0 > [root etc] > > I agree, /sbin/devd calls /etc/rc.d/dhclient which checks for the existence > of > a running dhclient. I find the rc scripts hard to follow but so far as I can > see /etc/rc.d/netif simply calls "ifconfig dhcp" and doesn't check for a > running dhclient. The head of the process group is completely irrelevent and has no effect. /etc/rc.d/netif litereally calls /etc/rc.d/dhclient is most definitly does not call "ifconfig dhcp" since no varient of that has ever worked. if dhcpif $1; then if [ $_cfg -ne 0 ] ; then ifconfig $1 up fi if syncdhcpif $1; then /etc/rc.d/dhclient start $1 fi _cfg=0 fi > Here are the relevant lines in my rc.conf: > > rc_debug="YES" > ifconfig_ral0="inet dhcp channel 10 wpa up" "inet" is wrong here and "channel 10" is pointless unless you're running an AP or in ad-hoc mode. You're basically luck that anything works for you since this generates a completely bogus ifconfig command. > devd_enable="YES" > > Here is the output of "/etc/rc.d/netif restart": > > [root etc]rc.d/netif restart > rc.d/netif: DEBUG: run_rc_command: doit: network_stop > Stopping network:Stopping wpa_supplicant. > /etc/rc.d/wpa_supplicant: DEBUG: run_rc_command: doit: kill -TERM 6229 > /etc/rc.d/dhclient: DEBUG: run_rc_command: doit: dhclient_stop > lo0 fwip0 fwe0 rl0 ral0 plip0rc.d/netif: DEBUG: The following interfaces > were > not configured: > . > rc.d/netif: DEBUG: run_rc_command: doit: network_start > rc.d/netif: DEBUG: Cloned: > Starting wpa_supplicant. > /etc/rc.d/wpa_supplicant: DEBUG: run_rc_command: > doit: /usr/sbin/wpa_supplicant -q -B -i ral0 -c /etc/wpa_supplicant.conf -D > bsd -P /var/run/wpa_supplicant/ral0.pid > rc.d/netif: DEBUG: checkyesno: synchronous_dhclient is set to YES. > /etc/rc.d/dhclient: DEBUG: run_rc_command: doit: dhclient_start > /etc/rc.d/dhclient: DEBUG: checkyesno: background_dhclient is set to NO. > ral0: no link got link > DHCPREQUEST on ral0 to 255.255.255.255 port 67 > DHCPDISCOVER on ral0 to 255.255.255.255 port 67 interval 8 > DHCPOFFER from 192.168.0.1 > DHCPREQUEST on ral0 to 255.255.255.255 port 67 > DHCPACK from 192.168.0.1 > bound to 192.168.0.4 -- renewal in 43200 seconds. > lo0: flags=8049 metric 0 mtu 16384 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff00 > ral0: flags=8843 metric 0 mtu 1500 > ether 00:xx: > inet 192.168.0.4 netmask 0xff00 broadcast 192.168.0.255 > media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/54Mbps) > status: associated > ssid channel 10 (2457 Mhz 11g) bssid 00:xx:. > authmode WPA privacy ON deftxkey UNDEF TKIP 3:128-bit txpower 50 > bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 > roam:rssi11g 7 roam:rate11g 5 protmode CTS roaming MANUAL > rc.d/netif: DEBUG: The following interfaces were not configured: fwip0 fwe0 > rl0 plip0 > /etc/rc.d/ipfilter: DEBUG: checkyesno: ipfilter_enable is set to NO. > > Now I have four dhclient processes: > > [root etc]ps -axj | grep dhclient > root9824 1 5727 57270 S ??0:00.00 dhclient: ral0 > [pri > _dhcp 9853 1 9853 98530 Ss??0:00.00 dhclient: ral0 > (dhc > _dhcp 9880 1 9880 98800 Ss??0:00.00 dhclient: ral0 > (dhc > root9826 1 9283 19160 S p00:00.00 dhclient: ral0 > [pri > > It seems that devd has started two new dhclients and netif has started its > own > pair as well. 1916 is the process id of the bash shell I su'ed from to > start /etc/rc.d/netif. Does you still set four processes in the steady state? That shouldn't happen since starting a second dhclient is supposed to kill the existing one. There should be two processes per interface due to the privege seperation model used by dhclient. -- Brooks pgpmIcYSRxecs.pgp Description: PGP signature
Current problem reports assigned to freebsd-net@FreeBSD.org
Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description a kern/38554 netchanging interface ipaddress doesn't seem to work s kern/39937 netipstealth issue f kern/62374 netpanic: free: multiple frees s kern/81147 net[net] [patch] em0 reinitialization while adding aliase o kern/92552 netA serious bug in most network drivers from 5.X to 6.X s kern/95665 net[if_tun] "ping: sendto: No buffer space available" wit s kern/105943 netNetwork stack may modify read-only mbuf chain copies o kern/106316 net[dummynet] dummynet with multipass ipfw drops packets o kern/108542 net[bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/112528 net[nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net[patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net[udp] IP v4 udp fragmented packet reject o kern/113457 net[ipv6] deadlock occurs if a tunnel goes down while the o kern/113842 net[ipv6] PF_INET6 proto domain state can't be cleared wi o kern/114714 net[gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net[fxp] fxp looses ability to speak with traffic o kern/115239 net[ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net[ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/116172 net[tun] [panic] Network / ipv6 recursive mutex panic o kern/116185 net[iwi] if_iwi driver leads system to reboot o kern/116328 net[bge]: Solid hang with bge interface o kern/116747 net[ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o kern/116837 net[tun] [panic] [patch] ifconfig tunX destroy: panic o kern/117043 net[em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/117271 net[tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117423 net[vlan] Duplicate IP on different interfaces o kern/117448 net[carp] 6.2 kernel crash (regression) o kern/118880 net[ipv6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented o kern/119225 net[wi] 7.0-RC1 no carrier with Prism 2.5 wifi card (regr o kern/119345 net[ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119361 net[bge] bge(4) transmit performance problem o kern/119548 net[pf] [ath] [patch] PF Altq with ath hostap problem o kern/120130 net[carp] [panic] carp causes kernel panics in any conste o kern/120266 net[panic] gnugk causes kernel panic when closing UDP soc o kern/120304 net[netgraph] [patch] netgraph source assumes 32-bit time 35 problems total. Non-critical problems S Tracker Resp. Description o conf/23063 net[PATCH] for static ARP tables in rc.network s bin/41647netifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net[nfs] [patch] NFS root configurations without dynamic s kern/60293 netFreeBSD arp poison patch o kern/95267 netpacket drops periodically appear f kern/95277 net[netinet] [patch] IP Encapsulation mask_match() return o kern/100519 net[netisr] suggestion to fix suboptimal network polling o kern/102035 net[plip] plip networking disables parallel port printing o conf/102502 net[patch] ifconfig name does't rename netgraph node in n o conf/107035 net[patch] bridge interface given in rc.conf not taking a o kern/109470 net[wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/114915 net[patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o bin/116643 net[patch] [request] fstat(1): add INET/INET6 socket deta o bin/117339 net[patch] route(8): loading routing management commands f kern/118722 net[tcp] Many old TCP connections in SYN_RCVD state o kern/118727 net[ng] [patch] [request] add new ng_pf module a kern/118879 net[bge] [patch] bge has checksum problems on the 5703 ch o kern/118975 net[bge] [patch] Broadcom 5906 not handled by FreeBSD o bin/118987 netifconfig(8): ifconfig -l (address_family) does not wor o kern/119432 net[arp] route add -host -iface causes arp e o kern/119617 net[nfs] nfs error on wpa network when reseting/shutdown o kern/119791 net[nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/120493 net[wpi] if_wpi.ko fails to load on a Toshiba Satellite P 23 problems total. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Wireless connection hangs using FreeBSD as AP
On Sun, 10 Feb 2008 19:55:23 -0500, Michael C. Cambria wrote > I have quite a few Soekris machines as wireless AP's using the > PCMCIA NL-2511 CD EXT card (wi0 in hostap mode) found at Netgate. I > also have a desktop with a similar setup, to debug prior to flashing > for Soekris. All run FreeBSD 4.10-Stable. > > I'm suddenly seeing a problem where wireless connections just hang. > However, the only time this happens is with clients that use non NL- > 2511 wireless cards . All my gear is NL-2511, all from Netgate. > > The problem is, just recently, friends and family come by with newer > laptops, they associate just fine, but connections just hang. In > all cases, the clients are XP (home or Pro), using newer laptops > that have Intel based 802.11a/b/g type cards. All work just fine to > off the shelf AP's around the globe. Only to my FreeBSD AP is there > an issue. > > Netgate suggested it was the wi driver, so another desktop was setup > to test as an AP. This uses FreeBSD 7 (just prior to any RC). The > result seems to be the same. > > The prism firmware for all prism cards is 1.4.9. > > Has anyone else seen this? Since all my personal gear is the same > family, I never experienced a problem until now. > > I do plan on moving to 802.11g, and migrating existing gear to > FreeBSD > 6.3/7.0 in the very near future. However, I'd like to get to the > bottom of this if possible. > > Thanks, > MikeC I too have noticed a similar problem with my Soekris boxes and Intel 3945abg clients, even with latest RELENG_7. And I use ath-based MiniPCI cards on the Soekris and ath seems to be the best choice for wireless in FreeBSD, all thanks to great work by Sam. I should mention that it's nearly impossible to troubleshoot this without additional information (athdebug, athstats, etc...). Sadly I have not had time to debug my setup either... Yuri ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Wireless connection hangs using FreeBSD as AP
On Sun, 10 Feb 2008 19:55:23 -0500, Michael C. Cambria wrote > I have quite a few Soekris machines as wireless AP's using the > PCMCIA NL-2511 CD EXT card (wi0 in hostap mode) found at Netgate. I > also have a desktop with a similar setup, to debug prior to flashing > for Soekris. All run FreeBSD 4.10-Stable. > > I'm suddenly seeing a problem where wireless connections just hang. > However, the only time this happens is with clients that use non NL- > 2511 wireless cards . All my gear is NL-2511, all from Netgate. > > The problem is, just recently, friends and family come by with newer > laptops, they associate just fine, but connections just hang. In > all cases, the clients are XP (home or Pro), using newer laptops > that have Intel based 802.11a/b/g type cards. All work just fine to > off the shelf AP's around the globe. Only to my FreeBSD AP is there > an issue. > > Netgate suggested it was the wi driver, so another desktop was setup > to test as an AP. This uses FreeBSD 7 (just prior to any RC). The > result seems to be the same. > > The prism firmware for all prism cards is 1.4.9. > > Has anyone else seen this? Since all my personal gear is the same > family, I never experienced a problem until now. > > I do plan on moving to 802.11g, and migrating existing gear to > FreeBSD > 6.3/7.0 in the very near future. However, I'd like to get to the > bottom of this if possible. > > Thanks, > MikeC > >I too have noticed a similar problem with my Soekris boxes and Intel 3945abg >clients, even with latest RELENG_7. And I use ath-based MiniPCI cards on the >Soekris and ath seems to be the best choice for wireless in FreeBSD, all >thanks to great work by Sam. I should mention that it's nearly impossible to >troubleshoot this without additional information (athdebug, athstats, >etc...). >Sadly I have not had time to debug my setup either... In your case, if you stick with wi, you'd probably want wlanstats and wlandebug. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD network stack Vs others
You have spoken about lots of optimization. and mainly talked about special cases concerned which syncache is one among them. where one can get more info about these features and more about enhancements for certain cases. Regards On Feb 4, 2008 11:15 PM, Andre Oppermann <[EMAIL PROTECTED]> wrote: > ithilgore wrote: > > Alfred Perlstein wrote: > >> * ithilgore -- <[EMAIL PROTECTED]> [080204 06:59] wrote: > >> > >>> I 'd like to learn what are the basic differences ( pros and cons ) > >>> between > >>> the > >>> FreeBSD network stack and the other OSs' ( especially linux ) > >>> > >>> I know that linux has had everything rewritten from scratch as far as > >>> the > >>> implementation of tcp-ip and the sockets are concerned and would like > to > >>> know if this has made it actually more robust or state-of-the-art than > >>> FreeBSD's or the opposite. > >>> > >>> Some actual technical details and references would be appreciated. > >>> > >> > >> Linux's stack hasn't been rewritten from the BSD one, it was written > >> from scratch. > >> > >> Linux's tcp/ip stack has been rewritten many times over the years > >> with the promise of large performance gains. > >> > >> The fact of the matter is that the performance on the "bleeding > >> edge" of both systems, FreeBSD and Linux, is about the same. > >> > >> From a BSD proponent's perspective, I would take the pragmatic > >> viewpoint that everytime Linux reinvents its stack to get performance > >> or some other feature FreeBSD isn't far behind with a relatively > >> minor change to its stack to accomplish the same feat. > >> > >> -Alfred > >> > > > > This means less work for the same gain, if it is as you say. > > FreeBSD's TCP/IP stack is a descendant of the original reference TCP/IP > implementation from the University of California at Berkeley. The > Internet > was pretty much invented and developed on the BSD operating system source > code. The reference standard book named "TCP/IP Illustrated Vol. 2" > describes > the BSD (and FreeBSD's) TCP/IP stack in great detail. This book is used > to > teach TCP/IP implementations to almost all Computer Science students all > over > the world. Of course FreeBSD has further refined the implementation and > added > support for RFCs features that came after the original code base. > > > As far as special cases are concerned, has FreeBSD taken extra care for > > them ? > > Yes. We have SYN flood attack protection (called syncache) and many more > advanced features. > > > Like for example error checking on more things or > > additional care for a special bad condition not to happen. > > What about the security hardening ? Would the FreeBSD network stack > > succumb less easily to attacks (supposing one doesn't use any additional > > protection mechanism ) ? > > No, the stack is *very* robust. You can't crash it. Though you have to > differentiate between attacks that try to cause the operating system to > break (which you can't on FreeBSD); and attacks that overload the (any) > system by opening so many connections that it can't deal with them > anymore. > Here we have pretty much all parts covered too. Syncache, compressed > time_ > wait states, etc. > > No to say something great can't improved further. I'm currently doing > that > with long term view. However the FreeBSD approach is evolutionary instead > of revolutionary as it happens so often on Linux. This gives us a very > stable and very proven long living code base. > > -- > Andre > > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > -- Faysal Banna Meteorological Services Rafic Harriri International Airport Beirut - Lebanon Mob: +961-3-258043 = ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
