Re: Netgraph VLAN in VLAN (q-in-q)
On 28 December 2011 11:37, wrote: > Hi! > > > If you need custom encap tag, use this: > http://www.freebsd.org/cgi/query-pr.cgi?pr=161908 > > Scheme: ng_ether <-> ng_vlan(outer/metro tag) <-> ng_vlan(inner/customer > tag) <-> ng_eiface Hm, have you found someone to review this and commit it to FreeBSD? Adrian ___ 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: Netgraph VLAN in VLAN (q-in-q)
Hi!
If you need custom encap tag, use this:
http://www.freebsd.org/cgi/query-pr.cgi?pr=161908
Scheme: ng_ether <-> ng_vlan(outer/metro tag) <-> ng_vlan(inner/customer
tag) <-> ng_eiface
> -Original Message-
> From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
> n...@freebsd.org] On Behalf Of Patrick Tracanelli
> Sent: Wednesday, December 28, 2011 11:33 PM
> To: freebsd-net@freebsd.org
> Subject: Netgraph VLAN in VLAN (q-in-q)
>
> Hello,
>
> I need to setup a typical q-in-q environment, here's what I am working
> on:
>
> ngctl mkpeer em2: vlan lower downstream
> ngctl name em2:lower vlanL1
> ngctl connect em2: vlanL1: upper nomatch
> ngctl mkpeer vlanL1: eiface
> vlan2589 ether ngctl msg vlanL1: addfilter '{ vlan=2589 hook="vlan2589" }'
>
> # assign em2 mac address
> ifconfig ngeth0 lladdr 00:21:5e:8a:0e:73
>
> # Do everything again but the new vlan will have the previous # as
> parent...
> ngctl mkpeer ngeth0: vlan lower downstream ngctl name ngeth0:lower
> vlanL2 ngctl connect ngeth0: vlanL2: upper nomatch ngctl mkpeer vlanL2:
> eiface vlan110 ether ngctl msg vlanL2: addfilter '{ vlan=110
> hook="vlan110" }'
>
> ifconfig ngeth1 lladdr 00:21:5e:8a:0e:73
>
> But when I run:
>
> # ngctl mkpeer ngeth0: vlan lower downstream
>
> I get:
>
> ngctl: send msg: Protocol family not supported
>
> I am clueless what I am doing wrong at this point. Can someone help me
> with this little ng problem?
>
> Its an 8.2-STABLE on i386 box.
>
> Thank you :)
>
> --
> Patrick Tracanelli
>
>
>
> ___
> 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"
___
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: Firewall Profiling.
Hello, Luigi. You wrote 28 декабря 2011 г., 14:42:51: > There is a problem here. You have to trust the native code > before allowing its execution in the kernel. So either you root could load any KLD. So, I think, we could trust any code "uploaded" via setsocopt()... Yes, it looks dangerous, but, again, if root is compromised, attacker could compile and load kernel module as well. > implement some form of sandboxing or code validator > before accepting a blob of native code from the setsockopt(), > or you generate the code directly within the kernel. > But with these sizes you cannot embed clang or gcc in the kernel: clang is bad example, it needs to process C/C++ code (frontend). Custom-written compiler with LLVM as backend could have very reasonable size. But not for kernel side, for sure, in any case! > though i would guess that a custom code generator is probably simpler > to write (perhaps reusing sys/i386/i386/bpf_jit_machdep.c and its > amd64 counterpart) Yep, as we have BPF JIT, it could be simpler. -- // Black Lion AKA Lev Serebryakov ___ 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"
Netgraph VLAN in VLAN (q-in-q)
Hello,
I need to setup a typical q-in-q environment, here's what I am working on:
ngctl mkpeer em2: vlan lower downstream
ngctl name em2:lower vlanL1
ngctl connect em2: vlanL1: upper nomatch
ngctl mkpeer vlanL1: eiface vlan2589 ether
ngctl msg vlanL1: addfilter '{ vlan=2589 hook="vlan2589" }'
# assign em2 mac address
ifconfig ngeth0 lladdr 00:21:5e:8a:0e:73
# Do everything again but the new vlan will have the previous
# as parent...
ngctl mkpeer ngeth0: vlan lower downstream
ngctl name ngeth0:lower vlanL2
ngctl connect ngeth0: vlanL2: upper nomatch
ngctl mkpeer vlanL2: eiface vlan110 ether
ngctl msg vlanL2: addfilter '{ vlan=110 hook="vlan110" }'
ifconfig ngeth1 lladdr 00:21:5e:8a:0e:73
But when I run:
# ngctl mkpeer ngeth0: vlan lower downstream
I get:
ngctl: send msg: Protocol family not supported
I am clueless what I am doing wrong at this point. Can someone help me with
this little ng problem?
Its an 8.2-STABLE on i386 box.
Thank you :)
--
Patrick Tracanelli
___
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: Firewall Profiling.
.. the idea was just to take the rules and generate a kld to load. There's no need to overly complicate things! Adrian ___ 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: ppp.conf "set speed" && UMTS
El día Wednesday, December 28, 2011 a las 12:06:11PM +0200, Aleksandr Rybalko escribió: > >> how those values fit with the speed of the device /dev/cuaU0.0 which > >> I set in ppp.conf to the maximum value as > >> > >> set speed 921600 > >> > >> and as well in /usr/include/sys/_termios.h I don't see any higher > >> possible speed for the interface... do I miss something? > >> > > Hi Matthias, > IIRC "set speed" ignored for USB modems (only USB-to-serial or USB > dialup modems use it). > > Some time ago I deal with that problem for linux based devices and > found that problem may be fixed by ignore reported USB endpoint > transfer size. Some devices report it with value 0x200 (512 bytes) but > works fine with 0x1000 (4096). And with last value give much bigger > throughput. > > This is wMaxPacketSize value in `usbconfig -u 4 -a 2 > dump_curr_config_desc` output. > > u3g driver already set it to 2048, if your modem hooked by another > driver try to change it from 0 (use reported) to 2048/4096. Hi Aleksandr, The device attaches to the u3g driver: /var/log/messages: ... Dec 28 08:01:20 tiny kernel: ugen4.4: at usbus4 Dec 28 08:01:20 tiny kernel: u3g0: on usbus4 Dec 28 08:01:20 tiny kernel: u3g0: Found 4 ports. and the usbconfig(8) gives the attached output below; most of the wMaxPacketSize values are 0x0200, some are 0x0040; which one should I change to 0x1000 (4096), and how? the source of the driver sys/dev/usb/serial/u3g.c has a #define for U3G_BSIZE set to 2048 and sets this into the structs for U3G_BULK_WR and U3G_BULK_RD, should this be visible with usbconfig(8)? the output below was done while the link is up; Thanks matthias # usbconfig -u 4 -a 4 dump_curr_config_desc ugen4.4: at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x00a1 bNumInterfaces = 0x0006 bConfigurationValue = 0x0001 iConfiguration = 0x0001 bmAttributes = 0x00e0 bMaxPower = 0x00fa Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x bAlternateSetting = 0x bNumEndpoints = 0x0003 bInterfaceClass = 0x00ff bInterfaceSubClass = 0x00ff bInterfaceProtocol = 0x00ff iInterface = 0x Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 bmAttributes = 0x0003 wMaxPacketSize = 0x0040 bInterval = 0x0005 bRefresh = 0x bSynchAddress = 0x Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0082 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x0020 bRefresh = 0x bSynchAddress = 0x Endpoint 2 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0001 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x0020 bRefresh = 0x bSynchAddress = 0x Interface 1 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0001 bAlternateSetting = 0x bNumEndpoints = 0x0003 bInterfaceClass = 0x00ff bInterfaceSubClass = 0x00ff bInterfaceProtocol = 0x00ff iInterface = 0x Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0083 bmAttributes = 0x0003 wMaxPacketSize = 0x0040 bInterval = 0x0005 bRefresh = 0x bSynchAddress = 0x Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0084 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x0020 bRefresh = 0x bSynchAddress = 0x Endpoint 2 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0002 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x0020 bRefresh = 0x bSynchAddress = 0x Interface 2 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0002 bAlternateSetting = 0x bNumEndpoints = 0x0002 bInterfaceClass = 0x00ff bInterfaceSubClass = 0x00ff bInterfaceProtocol = 0x00ff iInterface = 0x Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0085 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x0020 bRefresh = 0x bSynchAddress = 0x Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0003 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x
Re: Firewall Profiling.
On Wed, Dec 28, 2011 at 10:28:44AM +0400, Lev Serebryakov wrote: > Hello, Adrian. > You wrote 28 ??? 2011 ?., 10:04:13: > > > Maybe someone should write one and open source it this time.. :) > In presence of LLVM in the base, it looks, that we should generate > native code from IPFW bytecodes, without intermediate C code :) > Looks doeable! There is a problem here. You have to trust the native code before allowing its execution in the kernel. So either you implement some form of sandboxing or code validator before accepting a blob of native code from the setsockopt(), or you generate the code directly within the kernel. But with these sizes you cannot embed clang or gcc in the kernel: > size /usr/bin/clang textdata bss dec hex filename 31892505 538200 76544 325072491f00571 /usr/bin/clang > size /usr/libexec/cc1 textdata bss dec hex filename 6172008 39800 723320 6935128 69d258 /usr/libexec/cc1 maybe you can embed tcc or libtcc: > size `which tcc` textdata bss dec hex filename 127573 600 42680 170853 29b65 /usr/local/bin/tcc though i would guess that a custom code generator is probably simpler to write (perhaps reusing sys/i386/i386/bpf_jit_machdep.c and its amd64 counterpart) cheers luigi ___ 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: Compiling only "network" part of the kernel
On Tue, 27 Dec 2011 11:53:23 +0530
Rajneesh Kumar wrote:
>> Hi list,
>>
>> During my development, I want to check if my modules compile
>> successfully or not. I am only changing the ARP portion and whenever
>> I compile my kernel, it takes around 20mins and compiles all
>> different modules also. I just want to compile and check whether my
>> ARP modules, which I have changed, compile fine or not. How to do it?
hi,
or if you need rebuild only several modules with native build just do:
cd /usr/src/syc/modules/${required_module}
make
make install
:)
>>
>> --
>> Regards,
>> Rajneesh
>> ___
>> 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"
--
Alexandr Rybalko
aka Alex RAY
___
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: ppp.conf "set speed" && UMTS
On Tue, 27 Dec 2011 13:22:51 +0100 Matthias Apitz wrote: >> >> Hello, >> >> I'm using PPP with an USB UMTS stick (Huawei E1750). The speed for >> upload and download can be measured with, for example, pages like: >> http://www.speedtest.net/ >> the results vary of course a bit, but usually they are between >> 1 and 4 Mbps; >> >> how those values fit with the speed of the device /dev/cuaU0.0 which >> I set in ppp.conf to the maximum value as >> >> set speed 921600 >> >> and as well in /usr/include/sys/_termios.h I don't see any higher >> possible speed for the interface... do I miss something? >> Hi Matthias, IIRC "set speed" ignored for USB modems (only USB-to-serial or USB dialup modems use it). Some time ago I deal with that problem for linux based devices and found that problem may be fixed by ignore reported USB endpoint transfer size. Some devices report it with value 0x200 (512 bytes) but works fine with 0x1000 (4096). And with last value give much bigger throughput. This is wMaxPacketSize value in `usbconfig -u 4 -a 2 dump_curr_config_desc` output. u3g driver already set it to 2048, if your modem hooked by another driver try to change it from 0 (use reported) to 2048/4096. >> Thanks >> >> matthias >> -- >> Matthias Apitz >> e - w http://www.unixarea.de/ >> UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) >> UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 >> ___ >> 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" -- Alexandr Rybalko aka Alex RAY ___ 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: Firewall Profiling.
On Wed, Dec 28, 2011 at 10:26:44AM +0400, Lev Serebryakov wrote: > Hello, Luigi. > You wrote 27 ??? 2011 ?., 18:26:00: > > > plans, yes - not sure how long it will take. I have compiled > > ipfw+dummynet as a standalone module (outside the kernel) > > but have not yet hooked the code to netmap to figure out how fast > > it can run. > I still don't understand why it should be faster than "normal" way, > as it is essentially same (ipfw + dummynet) code + some additional > context switches for netmap (to userland and back). > What does netmap shave off from packet processing in this particular > case, to compensate context switches? I if you get called with reasonably large batches (10..50 packets, as it may well happen if you have any sort of interrupt mitigation), the context switch cost is amortised over the batch, so you shouldn't see much of it. If all the traffic goes to the local host you can't save anything. But if you manage to do the forwarding (so it's not just ipfw but also ip_fastforward) within the netmap layer, you save the recycling of mbufs (which is expensive), and also the code can be slightly optimized because packets have a single format, are contiguous, and carry almost no metadata. but definitely, the gains need to be measured and i have no such numbers so far. cheers luigi ___ 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: Transitioning if_addr_lock to an rwlock
2011/12/27 Gleb Smirnoff : > On Tue, Dec 27, 2011 at 11:29:02AM +0100, Ermal Lu?i wrote: > E> 2011/12/27 Gleb Smirnoff : > E> > On Thu, Dec 22, 2011 at 11:30:01AM -0500, John Baldwin wrote: > E> > J> You can find the patch for 8.x at > E> > J> http://www.freebsd.org/~jhb/patches/if_addr_rwlock.patch > E> > > E> > Just my two pennies: for head/ patching if ip_carp.c should > E> > be straightforward: > E> > > E> > 1) Using W in carp_alloc_if() and carp_free_if(). > E> > 2) Using R everywhere else. > E> > > E> > E> I would not say that is true! > E> > E> Look at this > https://github.com/bsdperimeter/pfsense-tools/blob/master/patches/RELENG_8_1/carp_livelock_fixes.diff > E> I already did this for carp on pfSense for 8.x and should be the same for > HEAD. > E> That has undergone testing and catching up where R vs W. > > Ermal, > > in head/ we already got new CARP implementation. > Gleb, yeah but the 'new' there is just the interface provided to be configured and not the protocol or code perse. To me it is the same from locking perspective in 8.x and HEAD For sure i will have to come to this when we move to 9 or HEAD in pfSense but still think its not that simple as you said. Regards, Ermal ___ 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: i386 compile sys/dev/ie
On 28 December 2011 10:58, Bruce Evans wrote: > On Wed, 28 Dec 2011, Bruce Evans wrote: > >> On Wed, 28 Dec 2011, Sergey Kandaurov wrote: > > >>> These were used in probe routine and are left from the newbus rewrite. >>> I hacked ie a bit to build cleanly. [Not sure if I did this correctly.] >> >> >> Use of the __DEVOLATILE() abomination is never correct. It exploits the >> bug that -Wcast-qual is broken for casts through [u]intptr_t. Agreed. > PS: I used to maintain some bad fixes in this area for ie, but now > have only the following: > > % .Index: if_ie.c > % .=== > % .RCS file: /home/ncvs/src/sys/dev/ie/if_ie.c,v > % .retrieving revision 1.99 > % .diff -u -2 -r1.99 if_ie.c > % .--- if_ie.c 17 Mar 2004 17:50:35 - 1.99 > % .+++ if_ie.c 31 May 2004 06:57:05 - > % .@@ -159,4 +159,7 @@ > % . #define IE_BUF_LEN ETHER_MAX_LEN /* length of transmit buffer */ > % . % .+/* XXX this driver uses `volatile' and `caddr_t' to a fault. */ > % .+typedef volatile char *v_caddr_t; /* core address, pointer to > volatile */ > % .+ > % . /* Forward declaration */ > % . struct ie_softc; Perhaps, it should be finally committed. :) > I never allowed the __DEFOO() abominations in my , and at > one time had all uses to them in /usr/src removed and ready to commit > (there were about 2 of them. There are hundreds if not thousands now :-(). > c_caddr_t and v_caddr_t are as abominable as __DEFOO(), so of course I > never allowed them in my . But v_caddr_t is still easy to > remove, since it is only used in the ie driver. It is used the break > warnings from -Wcast-qual that more natural casts would give (but warnings > still result from the implicit conversion for bcopy()): > > % if_ie.c:static v_caddr_t setup_rfa (struct ie_softc *, > v_caddr_t); > > The very idea of a v_caddr_t is nonsense. caddr_t is a bad old type for > a "core address". In most cases, it means the same as "void *", but was > used because "void *" didn't exist. In FreeBSD, it must be precisely > "char *" to work, since pointer arithmetic is perpetrated on it (the > pointer arithmetic defeats its opaqueness). In a few cases, it is > used for physical or device memory accesses. In must places, it should > be spelled "void *", and in other places it should be replaced by > a vm virtual or physical address type, or a bus space type. > > To this mess, the ie driver, but mercifully no other code in /usr/src, > adds v_caddr_t. caddr_t is supposed to be opaque, but if we just cast > to that we will get a cast-qual error if we start with one of ie's > excessively qualified pointers. Also, "const caddr_t" doesn't work > since it puts the const in the wrong place. This is "solved" by looking > inside caddr_t to add the const there. > > ie uses v_caddr_t as follows: > > First, in the above, some of the excessive qualifiers are in setup_rfa()'s > return type and second parameter... > > % if_ie.c: setup_rfa(sc, (v_caddr_t) sc->rframes[0]); > % if_ie.c: setup_rfa(sc, (v_caddr_t) sc->rframes[0]); /* ignore > cast-qual */ > > ... this makes even calling setup_rfa() difficult. We start with a > volatile struct ie_mumble **rframes. We can't just cast this to void * > or caddr_t since this would cause a -Wcast-qual warning. Casting it > to "volatile void *" would be even worse, since it removes a volatile > qualifier that is in the (technically) right place and adds it back in > a wrong place. So we use v_caddr_t to keep it in the same place. I should say for above that initially sc->rframes was: volatile struct ie_recv_frame_desc *rframes[MXFRAMES]; as well as its friends rbuffs, cbuffs, etc. Then it was changed to the current volatile ** form, and MXFRAMES was replaced to some dynamic value calculated from rman, so that gives even less chances to fix the ie code properly. /* * based on the amount of memory we have, allocate our tx and rx * resources. */ factor = rman_get_size(sc->mem_res) / 8192; sc->nframes = factor * NFRAMES; sc->nrxbufs = factor * NRXBUFS; sc->ntxbufs = factor * NTXBUFS; /* * Since all of these guys are arrays of pointers, allocate as one * big chunk and dole out accordingly. */ allocsize = sizeof(void *) * (sc->nframes + (sc->nrxbufs * 2) + (sc->ntxbufs * 3)); sc->rframes = (volatile struct ie_recv_frame_desc **) malloc(allocsize, M_DEVBUF, M_NOWAIT); then all these numerous buffs volatile friends point somewhere to this memory by setting its pointer to rframes like. sc->rbuffs = (volatile struct ie_recv_buf_desc **)&sc->rframes[sc->nframes]; This prompts me to that the vo
