Re: wireless monitoring of APs???
most APs have snmp ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
wireless monitoring of APs???
All this talk of tcpdump, etc. has made me remember a question I thought of a while back and never got a decent answer on... What tools are there in BSD-land that are usefull for monitoring activity on an AP? i.e. like dstumbler but from the LAN side? well, alright, not like dstumbler as it has 1) and installed piece of hardware to use and 2) direct access to the device, where as an AP attatched to a boxen does not... but surely you see my point? it would be desirable to be able to display on a BSD box the same sort of information as dstumbler or other network managent tools for APs as it is for on-board wifi cards... I suspect the problem is that there is no information coming from the AP on the ethernet activity it sees on the wireless side being relayed to the wired side... and hence a agent would have to be running on the AP itself to allow such functionality... -- Dr Paul van den Bergen Centre for Advanced Internet Architectures caia.swin.edu.au [EMAIL PROTECTED] IM:bulwynkl2002 "And some run up hill and down dale, knapping the chucky stones to pieces wi' hammers, like so many road makers run daft. They say it is to see how the world was made." Sir Walter Scott, St. Ronan's Well 1824 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ssh tunnels and Xvnc - (yes, I know... What? not again!?)
On Fri, 12 Dec 2003 09:01 pm, Willie Viljoen wrote: > > >from home you double tunnel: > > >LOCALPORT=6333 > > >REMOTEPORT=5901 > > >ssh -t -L $LOCALPORT:localhost:12945 work1 \ > > >ssh -L 12945:localhost:$REMOTEPORT work2 > > > > As home is a W2k box, ssh won't probably work exactly like this... > > > > Putty supports a "don't allocate a pseudo-terminal" option to achieve > > the effect of ssh's "-t" option. (Required, otherwise work1 will bark.) > > PuTTY is problematic though. There is a way to get it to work exactly like > this. A Windows NT/2000/XP/2003 port of OpenSSH with an installer is at > http://lexa.mckenna.edu/ > > The port installs a small subset of Cygwin and uses it to provide full > OpenSSH functionality, so you can get SSH as it is on UNIX from the Windows > command prompt. > > Will Neat! thanks, now I have to try it out (which requires a few moments at home uninterupted... good luck to me!) And thanks to everyone who helped with this... I was getting majorly confused... -- Dr Paul van den Bergen Centre for Advanced Internet Architectures caia.swin.edu.au [EMAIL PROTECTED] IM:bulwynkl2002 "And some run up hill and down dale, knapping the chucky stones to pieces wi' hammers, like so many road makers run daft. They say it is to see how the world was made." Sir Walter Scott, St. Ronan's Well 1824 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: how to saturate 100Mbit
On Sun, Dec 14, 2003 at 11:29:07AM +0700, Eugene Grosbein wrote: > > 100*1024*1024/8/1500=8738.1(3) SI in bits across a network is base 10, not 2 (1000 vs 1024). -- Richard A Steenbergen <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Controlling ports used by natd
On Sun, Dec 14, 2003 at 02:41:00PM -0500, Charles Swiger wrote: > On Dec 12, 2003, at 7:19 PM, Barney Wolff wrote: > >I have a real philosophical problem with ceding ports to worms, viruses > >and trojans. Where will it stop? Portno is a finite resource. > > This is a respectable position, but the notion of categorizing ranges > of ports into an association with a security policy already exists: > bindresvport(). > > Perhaps one could argue that this limitation isn't that meaningful now > that it's unfortunately common for malware to be running with root > privileges-- or the Windows equivalent, more likely. Still, if you and > your users don't run untrusted programs as root, system permissions > will prevent malware from acting as a rogue > DHCP/DNS/arp/routed/NMBD/whatever server, sniffing the local network, > etc...all of which contributes to slowing down the opportunities for > and rate at which a worm spreads. The difference is who gets to decide that a port or port range is reserved. I'm happy to cede authority to the IANA, or other standards body. I'm not willing to cede it to malware writers. Regardless of philosophy, correctly configured stateful firewalls do not need to prevent ordinary programs from binding particular source port numbers to prevent access to and spread of worms. It's enough to block particular dest ports on requests.* Statefulness is required to tell a UDP request from a response. * Actually, a sensible firewall config allows only needed ports and blocks all others. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Controlling ports used by natd
On Dec 12, 2003, at 7:19 PM, Barney Wolff wrote: I have a real philosophical problem with ceding ports to worms, viruses and trojans. Where will it stop? Portno is a finite resource. This is a respectable position, but the notion of categorizing ranges of ports into an association with a security policy already exists: bindresvport(). Perhaps one could argue that this limitation isn't that meaningful now that it's unfortunately common for malware to be running with root privileges-- or the Windows equivalent, more likely. Still, if you and your users don't run untrusted programs as root, system permissions will prevent malware from acting as a rogue DHCP/DNS/arp/routed/NMBD/whatever server, sniffing the local network, etc...all of which contributes to slowing down the opportunities for and rate at which a worm spreads. -- -Chuck ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fwd: 5.2-RC + ipfw
On Sun, 14 Dec 2003, 12:23-, Nate Grey wrote:
> On Saturday 13 December 2003 18:47, Maxim Konovalov wrote:
> > Please try an enclosed patch or put a whitespace right after the '('
> > before '\'.
> >
> > Index: ipfw2.c
> > ===
> > RCS file: /home/ncvs/src/sbin/ipfw/ipfw2.c,v
> > retrieving revision 1.42
> > diff -u -r1.42 ipfw2.c
> > --- ipfw2.c 31 Oct 2003 18:31:55 - 1.42
> > +++ ipfw2.c 13 Dec 2003 18:42:18 -
> > @@ -2901,15 +2901,14 @@
> > goto done;
> >
> > #define OR_START(target) \
> > - if (ac && (*av[0] == '(' || *av[0] == '{')) { \
> > + if (ac && ( \
> > + !strncmp(*av, "(", strlen(*av)) || \
> > + !strncmp(*av, "{", strlen(*av)) )) {\
> > if (open_par) \
> > errx(EX_USAGE, "nested \"(\" not allowed\n"); \
> > prev = NULL;\
> > open_par = 1; \
> > - if ( (av[0])[1] == '\0') { \
> > - ac--; av++; \
> > - } else \
> > - (*av)++;\
> > + ac--; av++; \
> > } \
> > target: \
> >
> > %%%
>
> Problem solved just adding a whitespace. Should I apply the patch anyway?
Please do if you can. Thanks.
--
Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fwd: 5.2-RC + ipfw
On Saturday 13 December 2003 18:47, Maxim Konovalov wrote:
> Please try an enclosed patch or put a whitespace right after the '('
> before '\'.
>
> Index: ipfw2.c
> ===
> RCS file: /home/ncvs/src/sbin/ipfw/ipfw2.c,v
> retrieving revision 1.42
> diff -u -r1.42 ipfw2.c
> --- ipfw2.c 31 Oct 2003 18:31:55 - 1.42
> +++ ipfw2.c 13 Dec 2003 18:42:18 -
> @@ -2901,15 +2901,14 @@
> goto done;
>
> #define OR_START(target) \
> - if (ac && (*av[0] == '(' || *av[0] == '{')) { \
> + if (ac && ( \
> + !strncmp(*av, "(", strlen(*av)) || \
> + !strncmp(*av, "{", strlen(*av)) )) {\
> if (open_par) \
> errx(EX_USAGE, "nested \"(\" not allowed\n"); \
> prev = NULL;\
> open_par = 1; \
> - if ( (av[0])[1] == '\0') { \
> - ac--; av++; \
> - } else \
> - (*av)++;\
> + ac--; av++; \
> } \
> target: \
>
> %%%
Problem solved just adding a whitespace. Should I apply the patch anyway?
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: how to saturate 100Mbit
On Sun, Dec 14, 2003 at 11:29:07AM +0700, Eugene Grosbein wrote: > On Sat, Dec 13, 2003 at 10:17:06AM -0800, Luigi Rizzo wrote: > > > the fxp has a problem which does not allow it to go above 103/110/120kpps > > depending on which descriptor model you use, no matter how fast > > the CPU is. > > Can you explain the problem, please? Sorry if i sound a bit vague but did these tests a couple of years ago, and i do not have access to the fxp specs or contacts with people who designed the chip so i cannot say what is exactly the problem. The problem is in the hardware, not in the driver. Apparently the chip wastes a lot of time (couple of microseconds if i remember well) between reading the descriptor and then transmitting the data. This extra delay is in parallel with some other chip activity, so for larger frames (say 256 bytes) it is completely masked and packets are transmitted at the nominal rate, but smaller packet are sent as if the interframe gap were larger than the standard. At the time i did a lot of experiments to make sure that the NIC was not stalled by the cpu not supplying frames in time, etc., and all tests confirmed the above diagnosis. BTW it is not something that has to do with flow control frames, because enabling/disabling them does not change the throughput (and you can see the frames when they are not disabled). Changing the way descriptor are used (there are two different formats, one has something like the data right after the descriptor) helped increase the performance to 120kpps, whereas the standard freebsd driver is stuck at something between 103 and 110kpps. Not that it matters terribly, just useful to know when you have to push small frames at line rate and you find you can't with those cards. There are others (e.g. intel/dec 2114x, 3com's xl, possibly others, plus probably all of the gbit units when used at 100Mbit) which work fine at line rate with 64-byte frames. > > Even not using any special kernel modules, a simple loop over > > a sendto() on a udp socket can achieve around 500kpps on a 2.4GHz > > box (em or bge). With some tricks and a sufficiently fast PCI > > bus you can reach some 750kpps but then it really depends > > on how fast is your PCI bus. A > > 100*1024*1024/8/1500=8738.1(3) > > It seems one does not need hundred of thousand pps to achive 100Mbps. certainly not, but because most of the time the overhead is mostly per packet, if you want to run performance tests you care about packets, not data rate. cheers luigi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
