Re: Why wpa_supplicant doesn't start with ndis0 interface?
On 09/13/2012 17:45, Warren Block wrote: On a fast machine, there could be a race there. Best to load them in order in a single command: @rebootroot/sbin/kldload if_ndis.ko && /sbin/kldload bcmwl5_sys.ko It was some mismatch between kernel/userland/ndis driver. After I fixed the mismatch, wifi still doesn't get initialized during boot and 'netif start' ran by hand also doesn't start it. Yuri ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: moving pfil consumers to sys/netpfil
On Fri, Sep 14, 2012 at 11:23:50AM +0400, Gleb Smirnoff wrote:
> On Thu, Sep 13, 2012 at 10:57:21PM +0200, Luigi Rizzo wrote:
> L> On Thu, Sep 13, 2012 at 11:31:25PM +0400, Gleb Smirnoff wrote:
> L> > On Thu, Sep 13, 2012 at 07:41:05PM +0200, Luigi Rizzo wrote:
> L> > L> Second:
> L> > L>What i contest is the fact that you classify ipfw as a "pfil
> client",
> L> > L>when pfil is just a tiny adaptation layer to access ipfw.
> L> > L>I mentioned the three alternative APIs (netmap, netfilter, ndis)
> L> > L>to witness the fact that pfil is irrelevant to ipfw's operation.
> L> >
> L> > In FreeBSD ipfw is a pfil client. Dot.
> L> >
> L> > In Linux it is netfilter client, and if they want to they may or may not
> L> > put it under netfilter/ipfw. We don't care. Same for Windows and ndis.
> L>
> L> This is the second time a "we don't care" statement appears in
> L> this discussion and I find them extremely non constructive.
>
> Don't take "we don't care" out of context! We don't care where ipfw
> resides in Linux or Windows. I don't see why we should to. We do care
> where pfil consumers reside in FreeBSD.
i am not taking it out of context, i am saying that deliberately
ignoring that this (or other) code is used elsewhere is not a sensible
thing to do -- it makes maintainance harder, reduces the chance of
getting bugfixes from the outside, etc. Not long ago there was a
thread on using wrappers to access ifnet fields so that third
parties have an easier time in using our code, and this is the
approach that we should follow.
So rather than "we don't care" i'd like to read "let's see if we can
find a solution that satisfies all". I take your offer to move the
code also in stable/9 as a step in this direction.
So, to somehow close the issue (as it seems a made decision)
> L> I do not know who you consider as "we", but as one who maintains
> L> the code under multiple platforms i do have an interest in avoiding
> L> gratuitous changes that introduce differences between the various
> L> versions.
>
> The movement is mergeable since userland doesn't depend on it. If you'd
> like I could merge movement to stable/9, so you won't have any differencies
> between maintained versions.
deal.
> L> please remain in context.
> L> We were talking about the files in netinet/ipfw, which have
> L>#include
> L> in them, so when moved to the new location these 35 lines
> L> need to be changed to
> L>#include
> L> Which is completely trivial, but introduces a difference between
> L> the files in HEAD and those in stable/9 (and in the other versions
> L> "we don't care" about) .
>
> Does ipfw resides in netinet/ipfw on other platforms: Linux, Windows?
right now yes (it's an external module, so the only real concern is
the hardwired netinet/ in the #includes).
I dont mind relocating it there too, as long as it is done everywhere.
> L> Now if your plan involves removing the netinet/ prefix and adding
> L>... compile-with "${NORMAL_C} -I$S/netpfil"
> L> to the lines in HEAD:sys/conf/files, and
> L>... compile-with "${NORMAL_C} -I$S/netinet"
> L> for those in stable/9, i can lift this objection.
>
> Don't see reason for -I. It compiles okay w/o it. See diff attached.
It compiles because you have all these tiny changes:
Index: sys/netpfil/ipfw/dn_heap.c
===
--- sys/netpfil/ipfw/dn_heap.c (working copy)
+++ sys/netpfil/ipfw/dn_heap.c (working copy)
@@ -37,7 +37,7 @@
#include
#include
#include
-#include
+#include
#ifndef log
#define log(x, arg...)
#endif
and not just a plain 'svn mv'.
> L> I still think that a subsystem should not be classified by looking
> L> at one of the APIs it uses, but rather based on overall functionality.
> L> Hence in my opinion ipfw does not belong under netpfil/ more than
> L> it belongs under netinet/ , and lacking a better place i consider
> L> the relocation a gratuitous one.
>
> Ipfw overall functionality is packet filtering. Since packet filtering
> can happen at different layers and protocols, none of the following
> directories suit perfectly: net, netinet, netinet6. Thus, we (me + Bjoern)
> decided to make a separate directory for packet filters. Since all
> packet filters attach to kernel via pfil(9) we decided to name
> the directory netpfil.
Up until now you were only talking about "pfil consumers",
and this is what i was disagreeing about.
Now you say netpfil/ is the home for "packet filters", which is a
different story, and one that makes sense to me (but it also means
that it can be used as the home for other packet filters even if
they do not use the pfil api).
So, it seems we have reached a compromise:
netpfil is the home for "packet filters", and ipfw goes there also
in stable/9 (or, if it is simpler, we remove the netinet/ prefix
from the #include and compile with -I ...).
ok ?
cheers
luigi
Re: moving pfil consumers to sys/netpfil
On Fri, Sep 14, 2012 at 10:33:40AM +0200, Luigi Rizzo wrote:
L> On Fri, Sep 14, 2012 at 11:23:50AM +0400, Gleb Smirnoff wrote:
L> > On Thu, Sep 13, 2012 at 10:57:21PM +0200, Luigi Rizzo wrote:
L> > L> On Thu, Sep 13, 2012 at 11:31:25PM +0400, Gleb Smirnoff wrote:
L> > L> > On Thu, Sep 13, 2012 at 07:41:05PM +0200, Luigi Rizzo wrote:
L> > L> > L> Second:
L> > L> > L>What i contest is the fact that you classify ipfw as a "pfil
client",
L> > L> > L>when pfil is just a tiny adaptation layer to access ipfw.
L> > L> > L>I mentioned the three alternative APIs (netmap, netfilter, ndis)
L> > L> > L>to witness the fact that pfil is irrelevant to ipfw's operation.
L> > L> >
L> > L> > In FreeBSD ipfw is a pfil client. Dot.
L> > L> >
L> > L> > In Linux it is netfilter client, and if they want to they may or may
not
L> > L> > put it under netfilter/ipfw. We don't care. Same for Windows and ndis.
L> > L>
L> > L> This is the second time a "we don't care" statement appears in
L> > L> this discussion and I find them extremely non constructive.
L> >
L> > Don't take "we don't care" out of context! We don't care where ipfw
L> > resides in Linux or Windows. I don't see why we should to. We do care
L> > where pfil consumers reside in FreeBSD.
L>
L> i am not taking it out of context, i am saying that deliberately
L> ignoring that this (or other) code is used elsewhere is not a sensible
L> thing to do -- it makes maintainance harder, reduces the chance of
L> getting bugfixes from the outside, etc. Not long ago there was a
L> thread on using wrappers to access ifnet fields so that third
L> parties have an easier time in using our code, and this is the
L> approach that we should follow.
L>
L> So rather than "we don't care" i'd like to read "let's see if we can
L> find a solution that satisfies all". I take your offer to move the
L> code also in stable/9 as a step in this direction.
L>
L> So, to somehow close the issue (as it seems a made decision)
L>
L> > L> I do not know who you consider as "we", but as one who maintains
L> > L> the code under multiple platforms i do have an interest in avoiding
L> > L> gratuitous changes that introduce differences between the various
L> > L> versions.
L> >
L> > The movement is mergeable since userland doesn't depend on it. If you'd
L> > like I could merge movement to stable/9, so you won't have any differencies
L> > between maintained versions.
L>
L> deal.
L>
L> > L> please remain in context.
L> > L> We were talking about the files in netinet/ipfw, which have
L> > L> #include
L> > L> in them, so when moved to the new location these 35 lines
L> > L> need to be changed to
L> > L> #include
L> > L> Which is completely trivial, but introduces a difference between
L> > L> the files in HEAD and those in stable/9 (and in the other versions
L> > L> "we don't care" about) .
L> >
L> > Does ipfw resides in netinet/ipfw on other platforms: Linux, Windows?
L>
L> right now yes (it's an external module, so the only real concern is
L> the hardwired netinet/ in the #includes).
L> I dont mind relocating it there too, as long as it is done everywhere.
L>
L> > L> Now if your plan involves removing the netinet/ prefix and adding
L> > L> ... compile-with "${NORMAL_C} -I$S/netpfil"
L> > L> to the lines in HEAD:sys/conf/files, and
L> > L> ... compile-with "${NORMAL_C} -I$S/netinet"
L> > L> for those in stable/9, i can lift this objection.
L> >
L> > Don't see reason for -I. It compiles okay w/o it. See diff attached.
L>
L> It compiles because you have all these tiny changes:
L>
L> Index: sys/netpfil/ipfw/dn_heap.c
L> ===
L> --- sys/netpfil/ipfw/dn_heap.c (working copy)
L> +++ sys/netpfil/ipfw/dn_heap.c (working copy)
L> @@ -37,7 +37,7 @@
L> #include
L> #include
L> #include
L> -#include
L> +#include
L> #ifndef log
L> #define log(x, arg...)
L> #endif
L>
L> and not just a plain 'svn mv'.
L>
L> > L> I still think that a subsystem should not be classified by looking
L> > L> at one of the APIs it uses, but rather based on overall functionality.
L> > L> Hence in my opinion ipfw does not belong under netpfil/ more than
L> > L> it belongs under netinet/ , and lacking a better place i consider
L> > L> the relocation a gratuitous one.
L> >
L> > Ipfw overall functionality is packet filtering. Since packet filtering
L> > can happen at different layers and protocols, none of the following
L> > directories suit perfectly: net, netinet, netinet6. Thus, we (me + Bjoern)
L> > decided to make a separate directory for packet filters. Since all
L> > packet filters attach to kernel via pfil(9) we decided to name
L> > the directory netpfil.
L>
L> Up until now you were only talking about "pfil consumers",
L> and this is what i was disagreeing about.
L>
L> Now you say netpfil/ is the home for "packet filters", which is a
L> different story, and on
Re: ISDN4BSD (HPS version) is going into ports
Hi, Problem 2: I tried to get more information for problem 1 with the analyze mode of isdndecode using the custom cable as decribed in cable.txt. I connected my ISDN phone to an "ISDN Basisanschluß" with my cable box between them (receiving side unit 8, sending side unit 9), but after the commands cat /dev/ihfc8.X > /dev/null 2>&1 &(X=0,1,2) cat /dev/ihfc9.X > /dev/null 2>&1 & isdndecode -a -b -R 8 -T 9 -i -x > You need to run something like this first: > isdndebug -u 9 -b 0 -p P_HDLC -b 1 P_HDLC -b 2 P_TRANSPARENT > If it doesn't work, I will check later. A bit busy right now. Thanks for this. The D-channel trace works correct with your isdndebug command, but no luck with B-cahnnels. I also tried isdndebug -u 9 -b 0 -p P_HDLC -b 1 -p P_TRANS -b 2 -p P_TRANS and isdndebug -u 9 -b 0 -p P_HDLC -b 1 -p P_TRANS_RING -b 2 -p P_TRANS_RING with the same result: D-channel ok, B-channels give only X'FF'. I am not sure, if I had ever traced B-channel data in analyze mode successful before. -- Andreas Longwitz ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kernel: arpresolve: can't allocate llinfo for 65.59.233.102
Ok, I will disable vlan_hwtso using ifconfig -vlanhwtso. Thanks. > Try disabling tso at the global level in the kernel. Under some > circumstances with some drives VLAN_HWTSO -> TSO. > -Garrett > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Why wpa_supplicant doesn't start with ndis0 interface?
On 09/14/2012 00:09, Yuri wrote: It was some mismatch between kernel/userland/ndis driver. After I fixed the mismatch, wifi still doesn't get initialized during boot and 'netif start' ran by hand also doesn't start it. Never mind, it was an issue of /etc out of sync with the world. Yuri ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Why wpa_supplicant doesn't start with ndis0 interface?
On Fri, Sep 14, 2012 at 10:47:38AM -0700, Yuri wrote: > On 09/14/2012 00:09, Yuri wrote: > > > > It was some mismatch between kernel/userland/ndis driver. After I > > fixed the mismatch, wifi still doesn't get initialized during boot and > > 'netif start' ran by hand also doesn't start it. > > Never mind, it was an issue of /etc out of sync with the world. > Ok. Thanks for letting us know. Glen pgpxmNz1xreDo.pgp Description: PGP signature
Re: Why wpa_supplicant doesn't start with ndis0 interface?
On 09/14/2012 10:54, Glen Barber wrote: Ok. Thanks for letting us know. Now wpa_supplicant starts and is operational, however '/etc/rc.d/netif start' always issues this warning: Starting wpa_supplicant /etc/rc.d/wpa_supplicant: WARNING: failed to start wpa_supplicant Starting Network: lo0 ndis0 re0. Also (as a result) dhclient isn't started, but succeeds when started manually. wpa_supplicant started by hand doesn't print any errors. I can't find any option in wpa_supplicant.conf making it to write a log what is wrong. On linux it seems to be -f option for the log file. Any way to make netif more verbose? Yuri ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Why wpa_supplicant doesn't start with ndis0 interface?
On Fri, Sep 14, 2012 at 11:32 AM, Yuri wrote: > On 09/14/2012 10:54, Glen Barber wrote: > >> Ok. Thanks for letting us know. >> > > Now wpa_supplicant starts and is operational, however '/etc/rc.d/netif > start' always issues this warning: > Starting wpa_supplicant > /etc/rc.d/wpa_supplicant: WARNING: failed to start wpa_supplicant > Starting Network: lo0 ndis0 re0. > > Also (as a result) dhclient isn't started, but succeeds when started > manually. > wpa_supplicant started by hand doesn't print any errors. > > I can't find any option in wpa_supplicant.conf making it to write a log > what is wrong. On linux it seems to be -f option for the log file. > Any way to make netif more verbose? Not sure if you looked at - man wpa_supplicant, which has -d for debugging -s for pumping messages to syslog Thanks, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Why wpa_supplicant doesn't start with ndis0 interface?
On 09/14/2012 11:49, hiren panchasara wrote: Not sure if you looked at - man wpa_supplicant, which has -d for debugging -s for pumping messages to syslog wpa_supplicant ran with -d -d doesn't print any error messages and runs fine. 'netif start' is the one issuing a warning and preventing dhclient from start. I am asking how to increase the verbosity and determine why netif thinks wpa_supplicant fails. Yuri ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
