Re: question about captive wifi portal...
On Jan 14, 2008 8:35 AM, Lyle Scott III <[EMAIL PROTECTED]> wrote: > I am experimenting more to make a small captive (wifi) portal system. > > I would like to use pf. I have been looking into authpf and it is a pretty > good fit for what i need... but the users won't be SSHing to get allowed. > > Is there another way around this? Does anyone else have and suggestions or > links that could be helpful? > > I also thought i could just use packet marks, but I am just unaware of > anything else to make the pf packets more dynamic... i guess that would be > the goal of this post > > -- > Lyle Scott, III > http://www.lylescott.ws Hi, pfSense[1], a FreeBSD based router/firewall distribution has integrated captive portal using pf. Maybe you'll want to check how they are doing this. [1] http://pfsense.com HTH, Niki ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Current problem reports assigned to freebsd-net@FreeBSD.org
Current FreeBSD problem reports Critical problems S Tracker Resp. Description f kern/115360 net[ipv6] IPv6 address and if_bridge don't play well toge 1 problem total. 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 netIP 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 net6.2-STABLE panic during use of multi-cast networking c o kern/116172 netNetwork / ipv6 recursive mutex panic o kern/116185 netif_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 f kern/119548 net[pf] [ath] [patch] PF Altq with ath hostap problem 32 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/112654 net[pcn] Kernel panic upon if_pcn module load on a Netfin o kern/114915 net[patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o bin/116643 net[patch] fstat(1): add INET/INET6 socket details as in 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] 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 22 problems total. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Programming interface MAC filter without enabling PROMISC on an interface from user space.
Hi, I have just started experimenting with OpenLLDP and come across a little bit of a nasty. When it opens the interface, it puts it into PROMISC mode, which I don't really want to happen. Is there any way to add the LLDP MAC address (01-80-C2-00-00-0E) to the interface mac filter from user space, so that the interface does not have to be set to PROMISC? The OpenLLDP uses BPF to interface with the network stack as it has to send and receive RAW Ethernet frames (ether type 88-CC). If this is not possible where would one start with moving the LLDP implementation into the kernel. I was thinking of 3 options: * Having a virtual interface (like vlan/carp) that attaches to a parent that processes the packages. * A netgraph node to processes the packets and send responses. * A core protocol handler that deals with the hole thing for any Ethernet capable interface. Any help with this would be greatly appreciated. Tom ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Added native socks support to libc in FreeBSD 7
Upgrade: 1) Added IPv6 Support (need to be tested) Cheers Raffaele Hi, i added a native (client) Socks V4/V5 support inside FreeBSD libc library. The work is based of my project (see http://csocks.altervista.org) CSOCKS. You can get it here: http://csocks.altervista.org/download/FreeBSD_libc.tar.gz CHANGES: I changed the file: /usr/src/lib/libc/Makefile I added the Directory: /usr/src/lib/libc/socks They contains the files: csocks.c csocks.h csocks.conf.5 csocks.1 Makefile.inc I added the configuration file (csocks.conf in the /etc/ directory) /usr/src/etc/ INSTALL ISTRUCTIONS: copy the Makefile in /usr/src/lib/libc/ copy the directory socks in /usr/src/lib/libc/ touch /etc/csocks.conf recompile the libc and install it (cd /usr/src/lib/libc && make && make install) I Tested it in FreeBSD 7 only on i386 cheers Raffaele ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Programming interface MAC filter without enabling PROMISC on an interface from user space.
Tom Judge wrote: Hi, I have just started experimenting with OpenLLDP and come across a little bit of a nasty. When it opens the interface, it puts it into PROMISC mode, which I don't really want to happen. Is there any way to add the LLDP MAC address (01-80-C2-00-00-0E) to the interface mac filter from user space, so that the interface does not have to be set to PROMISC? There *is* an API for this but it's not integrated into pcap or bpf; see SIOCADDMULTI and SIOCDELMULTI. There are some issues with doing that portably, Windows and Linux do things somewhat differently in this space. Really we could do with a KPI for this so that the references are properly refcounted. If you have other link layer multicast listeners it's not guaranteed that the stack will correctly restore the hash filters at the driver level if it has to enable ALLMULTI mode. You almost certainly don't want to set PROMISC if you are ever going to do any kind of IP forwarding, although I believe I fixed that historic bug whereby the IP layer kept seeing its own packets about a year ago. later BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Programming interface MAC filter without enabling PROMISC on an interface from user space.
Bruce M. Simpson wrote:
Tom Judge wrote:
Hi,
I have just started experimenting with OpenLLDP and come across a
little bit of a nasty. When it opens the interface, it puts it into
PROMISC mode, which I don't really want to happen. Is there any way
to add the LLDP MAC address (01-80-C2-00-00-0E) to the interface mac
filter from user space, so that the interface does not have to be set
to PROMISC?
There *is* an API for this but it's not integrated into pcap or bpf; see
SIOCADDMULTI and SIOCDELMULTI. There are some issues with doing that
portably, Windows and Linux do things somewhat differently in this space.
Really we could do with a KPI for this so that the references are
properly refcounted. If you have other link layer multicast listeners
it's not guaranteed that the stack will correctly restore the hash
filters at the driver level if it has to enable ALLMULTI mode.
You almost certainly don't want to set PROMISC if you are ever going to
do any kind of IP forwarding, although I believe I fixed that historic
bug whereby the IP layer kept seeing its own packets about a year ago.
later
BMS
Hi Bruce,
Thanks for the response. I have a quick grep of the src tree to find an
example of this being used and only found the following from
wpa_supplicant and I have a few questions:
* I am presuming that this will do what I want, am I correct?
* If I was only ever to add the address to an interface an never delete
it would this cause any problems? I.e. when lldpd ends, or is restarted
and tries to add the address again?
* Alternatively is there a way to query the filter to ask what
addresses it is currently programmed for?
At this stage I am not looking for portability, I just want a working
solution for a FreeBSD only shop.
Thanks again
Tom
From contrib/wpa_supplicant/driver_wired.c:
static int wpa_driver_wired_multi(const char *ifname, const u8 *addr,
int add)
{
struct ifreq ifr;
int s;
s = socket(PF_INET, SOCK_DGRAM, 0);
if (s < 0) {
perror("socket");
return -1;
}
memset(&ifr, 0, sizeof(ifr));
strncpy(ifr.ifr_name, ifname, IFNAMSIZ);
ifr.ifr_hwaddr.sa_family = AF_UNSPEC;
memcpy(ifr.ifr_hwaddr.sa_data, addr, ETH_ALEN);
if (ioctl(s, add ? SIOCADDMULTI : SIOCDELMULTI, (caddr_t) &ifr) < 0) {
perror("ioctl[SIOC{ADD/DEL}MULTI]");
close(s);
return -1;
}
close(s);
return 0;
}
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/119361: [bge] bge(4) transmit performance problem
On Fri, Jan 11, 2008 at 10:02:34PM +0800, Sepherosa Ziehau wrote: > On Jan 8, 2008 1:28 AM, <[EMAIL PROTECTED]> wrote: > > Synopsis: [bge] bge(4) transmit performance problem > > > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > > Responsible-Changed-By: remko > > Responsible-Changed-When: Mon Jan 7 17:28:37 UTC 2008 > > Responsible-Changed-Why: > > reassign to -net team > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=119361 > > Have you tested polling(4)? If polling could give you better TX > performance, you should consider raise: > in bge_attach() > sc->bge_tx_max_coal_bds = 10; > to 64 or more I tested with polling and did not see any changes for the transmit performance problem. I just re-test with polling AND bge_tx_max_coal_bds raised to 64 => no changes. Regards, -- Laurent Frigault ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Programming interface MAC filter without enabling PROMISC on an interface from user space.
Tom Judge wrote: Thanks for the response. I have a quick grep of the src tree to find an example of this being used and only found the following from wpa_supplicant and I have a few questions: * I am presuming that this will do what I want, am I correct? Yes, it will attempt to add the given link layer multicast group to the ifnet's underlying device driver. * If I was only ever to add the address to an interface an never delete it would this cause any problems? I.e. when lldpd ends, or is restarted and tries to add the address again? SIOCADDMULTI is very low level, no resource tracking is performed; I changed its semantics to only allow one userland opener so that in-kernel refcounting would work, as there is no per-process or per-client resource tracking -- so it's a really good idea to clean up after it. * Alternatively is there a way to query the filter to ask what addresses it is currently programmed for? Nope, there is no userland or kernel API for that unless you hack up the driver. cheers BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Programming interface MAC filter without enabling PROMISC on an interface from user space.
Tom Judge wrote: Ok, so if I can safely assume that the process sending/receiving the LLDP frames should always be running would it be safe to use a helper program to add the mac on system startup so it is always registered on particular interfaces for the uptime of the system rather than having the daemon add/remove the address on startup shutdown? If not what problems would this create? If the daemon doesn't unregister its use of the link layer group, the kernel will not clean up after it. It won't prevent kernel entities from joining the group -- they will just acquire another reference -- but other userland clients will not be able to join the group until SIOCDELMULTI is called by at least one client. By the way, other processes can hijack this, but only if they have permission to use SIOCDELMULTI. I believe this requires root privileges. I believe it should be possible to use mtest to clean up manually. This is far from ideal and it really does want an API. NDIS, incidentally, can do all of what you describe. Personally I can't see why this approach would be a problem, but I am not a expert. The address is defined in IEEE Std 802.1D-2004 as to not be forwarded by bridges (which I interpret as it being link local in a sense as switches/bridges are not allowed to forward the frame), so I can't see it being a problem registered on multiple interfaces. SIOCADDMULTI memberships are specific to the interface you request them on. I can't speak for the bridging code -- I don't think it does any special handling of multicast frames, however I'm not sure if it's smart enough not to forward this group. Like IN_LOCALGROUP() it might need its own 'don't forward this' clause. later BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Programming interface MAC filter without enabling PROMISC on an interface from user space.
Bruce M. Simpson wrote: Tom Judge wrote: Thanks for the response. I have a quick grep of the src tree to find an example of this being used and only found the following from wpa_supplicant and I have a few questions: * I am presuming that this will do what I want, am I correct? Yes, it will attempt to add the given link layer multicast group to the ifnet's underlying device driver. * If I was only ever to add the address to an interface an never delete it would this cause any problems? I.e. when lldpd ends, or is restarted and tries to add the address again? SIOCADDMULTI is very low level, no resource tracking is performed; I changed its semantics to only allow one userland opener so that in-kernel refcounting would work, as there is no per-process or per-client resource tracking -- so it's a really good idea to clean up after it. * Alternatively is there a way to query the filter to ask what addresses it is currently programmed for? Nope, there is no userland or kernel API for that unless you hack up the driver. Ok, so if I can safely assume that the process sending/receiving the LLDP frames should always be running would it be safe to use a helper program to add the mac on system startup so it is always registered on particular interfaces for the uptime of the system rather than having the daemon add/remove the address on startup shutdown? If not what problems would this create? Personally I can't see why this approach would be a problem, but I am not a expert. The address is defined in IEEE Std 802.1D-2004 as to not be forwarded by bridges (which I interpret as it being link local in a sense as switches/bridges are not allowed to forward the frame), so I can't see it being a problem registered on multiple interfaces. On a side note does anyone know if if_bridge will respect the standard and not forward this frame on to other interfaces? Thanks again Tom ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bgp router preferences
On Sat, 12 Jan 2008 18:13:22 -0500, in sentex.lists.freebsd.net you wrote: >I think I have finally given up on cisco. > >What are folks recommendations for a machine doing full bgp routes? > >I think I need to get a Sangoma card; but what is the current favorite I am not sure the card is still supported under FreeBSD. Do you really need T1 connectivity ? >bgp routing software and how much RAM do folks think I can get away with? Quagga and 1G of RAM is plenty. 512 will work just fine, but splurge on the extra $50 to give you a bit more room :) ---Mike Mike Tancsa, Sentex communications http://www.sentex.net Providing Internet Access since 1994 [EMAIL PROTECTED], (http://www.tancsa.com) ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/119361: [bge] bge(4) transmit performance problem
On Jan 15, 2008 12:07 AM, Laurent Frigault <[EMAIL PROTECTED]> wrote: > On Fri, Jan 11, 2008 at 10:02:34PM +0800, Sepherosa Ziehau wrote: > > On Jan 8, 2008 1:28 AM, <[EMAIL PROTECTED]> wrote: > > > Synopsis: [bge] bge(4) transmit performance problem > > > > > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > > > Responsible-Changed-By: remko > > > Responsible-Changed-When: Mon Jan 7 17:28:37 UTC 2008 > > > Responsible-Changed-Why: > > > reassign to -net team > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=119361 > > > > Have you tested polling(4)? If polling could give you better TX > > performance, you should consider raise: > > in bge_attach() > > sc->bge_tx_max_coal_bds = 10; > > to 64 or more > > I tested with polling and did not see any changes for the transmit > performance problem. > > I just re-test with polling AND bge_tx_max_coal_bds raised to 64 => no > changes. Please test following patch: http://people.freebsd.org/~sephe/if_bge.c.6.diff Best Regards, sephe -- Live Free or Die ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Linux SMP network performance measurements
Hello, a recent article (http://www.ibm.com/developerworks/linux/library/l-scalability/?ca=dgr-lnxw02FasterLinuxNet) gives some measurements on various tweakings of an SMP machine with 4 Xeon processors (it *shows* a nice improvement when using more CPUs and more bonded Ethernet interfaces). Has some the machine (and the time, obviously) to make some of the same measurements with the latest FreeBSD versions ? TfH ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
