Re: [net] protecting interfaces from races between control and data ?
On Aug 5, 2013, at 11:20 AM, Adrian Chadd wrote: .. and I bet it's not a design pattern, and this is total conjecture on my part: * the original drivers weren't SMP safe; * noone really sat down and figured out how to correctly synchronise all of this stuff; * people did the minimum amount of work to keep the driver from immediately crashing, but didn't really think things through at a larger scale. Almost every driver is this way Luigi. :-) Most of the drivers in the three don't support hardware that performs well enough for this to be a problem. :) Any driver that's still around from the pre-locking days can easily saturate the lines (or the hardware) on today's (and even yesterday's hardware). All the rest have come up with different ways to cope... Warner ___ 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
how calculate the number of ip addresses in a range?
hello guys, i have a question about ip addresses. i know my question is not related to freebsd but i googled a lot and found nothing useful and don't know where i should ask my question. i want to know how can i calculate the number of ip addresses in a range? for example if i have 192.0.0.1 192.100.255.254 with mask 8, how many ip addresses are available in this range? is there any formula to calculate the number of ip addresses for any range? i'm confusing about it. please help me to clear my mind. thanks in advance, SAM ___ 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: BPF_MISC+BPF_COP and BPF_COPX
On 8/08/2013 3:55 AM, Mindaugas Rasiukevicius wrote: Darren Reed darr...@netbsd.org wrote: I would like propose new BPF instructions for the misc category: BPF_COP and BPF_COPX. It would provide a capability of calling an external function - think of BPF coprocessor. No. You do not have to use it. I get no choice - it is in the kernel by default. A BPF program is an entity that can be verified as correct from a security perspective.It is also self contained and requires no external references in order to understand. This change brakes the BPF security model because now the BPF program is calling out to some random function as part of the packet matching. BPF byte-code can still be verified. You cannot call random functions, the functions are predetermined and cannot change during the life-cycle. There is a difference. However, it is as secure as calling any other function in the kernel on packet transmission. You can make a bug in your function, but you can as well make it in tcp_input(). No. It's not about calling a function, it is about proving the BPF program is correct and secure. BPF today is essentially assembly language operations that are all easily tested and verified. It provides us a capability to offload more complex packet processing. My primary user would be NPF in NetBSD, e.g. one of the operations is to lookup an IP address in a table/ipset. Then add BPF instructions to manipulate address sets (add, remove, lookup) and pick a datastore to use to support it. How adding specialised random instructions is better than having a generic mechanism? You mean BPF_SOME_LOOKUP calling some_lookup() suddenly becomes more secure than BPF_MISC+BPF_COP calling the same some_lookup()? See below. On 8/08/2013 5:18 AM, Joerg Sonnenberger wrote: On Thu, Aug 08, 2013 at 01:35:24AM +1000, Darren Reed wrote: A BPF program is an entity that can be verified as correct from a security perspective.It is also self contained and requires no external references in order to understand. How is this relevant for the discussion? It is important to understand what BPF is before making changes to it. It provides us a capability to offload more complex packet processing. My primary user would be NPF in NetBSD, e.g. one of the operations is to lookup an IP address in a table/ipset. Then add BPF instructions to manipulate address sets (add, remove, lookup) and pick a datastore to use to support it. How is that more useful than the proposal? Actually, add/remove are not instructions for the BPF language, only lookup. Add, remove, etc, would be handled in the usual manner. How is that more useful? The capability of the opcodes is programmed into the BPF program, not through some external reference. A BPF program generated on Linux is just as valid as on Solaris or NetBSD. Whilst that may be meaningless because nobody copies BPF programs around (in byte code format), this would open a door on developing specialised behaviour for my platform that isn't present elsewhere. This then diminishes the value of BPF. The BPF design has some serious limitations for modern network protocols. For example, the forward-jump-only property makes it impossible to write rules for protocols with arbitrary header composition. While it is not desirable to completely remove this restriction, the proposal could help to deal with many of the interesting case efficently. Correct. The forward jumping only aspect is an important attribute of BPF as it bounds the amount of time that the system can spend on processing the packet. Given that BPF opcodes are evaluated in the hot patch of packet processing, that kind of guarantee is very important. I think your reference here to arbitrary header ordering is in reference to IPv6 - which actually does have some rules about in which order headers can be found. Just as IPv4 has a special instruction with which to find the start of a transport header, I see no reason why something similar shouldn't exist for IPv6. The challenge becomes to think of processing the packet differently and how the relationship between BPF and the packet dictates what instructions are necessary. Darren ___ 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: how calculate the number of ip addresses in a range?
On Thu, Aug 8, 2013 at 12:04 AM, s m sam.gh1...@gmail.com wrote:
hello guys,
i have a question about ip addresses. i know my question is not related to
freebsd but i googled a lot and found nothing useful and don't know where i
should ask my question.
i want to know how can i calculate the number of ip addresses in a range?
for example if i have 192.0.0.1 192.100.255.254 with mask 8, how many ip
addresses are available in this range? is there any formula to calculate
the number of ip addresses for any range?
i'm confusing about it. please help me to clear my mind.
thanks in advance,
My immediate reaction is.. is this a homework / classwork / assignment?
Anyway, you can think of it by converting your start and end addresses
to an integer. Over simplified:
$ cat homework.c
main()
{
int start = (192 24) | (0 16) | (0 8) | 1;
int end = (192 24) | (100 16) | (255 8) | 254;
printf(start %d end %d range %d\n, start, end, (end - start) + 1);
}
$ ./homework
start -1073741823 end -1067122690 range 6619134
The +1 is correcting for base zero. 192.0.0.1 - 192.0.0.2 is two
usable addresses.
I'm not sure what you want to do with the mask of 8.
You can also do it with ntohl(inet_addr(address)) as well and a
multitude of other ways.
--
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' just won\342\200\231t do.
brueffer ZFS must be the bacon of file systems. everything's better with ZFS
___
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: BPF_MISC+BPF_COP and BPF_COPX
On Aug 8, 2013, at 1:14 AM, Darren Reed darr...@netbsd.org wrote: A BPF program generated on Linux is just as valid as on Solaris or NetBSD. Not necessarily - negative offsets in load and store instructions are supported on Linux to access some metadata that's not in the packet data, but those aren't, as far as I know, supported on other platforms. However, there is a subset of BPF that all kernel BPF implementations, and the userland implementation in libpcap, support. ___ 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: BPF_MISC+BPF_COP and BPF_COPX
Alexander Nasonov al...@yandex.ru wrote: Mindaugas Rasiukevicius wrote: Why is it a problem? Given that the byte-code and the functions would come from the same source, some coupling seems natural to me. It is simplistic anyway: some already parsed offsets or values could be passed through the memory store. You surely have some picture in mind but I can't get it. I'm a bit worried that two different environments may look unnatural when married together. OK, but you did not explain why is it a problem i.e. why is it worrying? Perhaps, you should right a proposal with some use-cases to support your points. They are simple: consider detecting IP version and calculating the offset to L4 header. There is no reason to duplicate this work in the byte-code and the coprocessor. If one of them does it - let's just save it. Ah, you plan to generalize scratch memory. It's probably fine but don't generalize too many things because people (me at least) want to be able to recognize the original bpf and its orignal design. Well, you suggested getter/setter. :) Yeah, please write a proposal ;-) int bpf_get_memword(const bpf_ctx_t *c, size_t i, uint32_t *val); int bpf_set_memword(bpf_ctx_t *c, size_t i, uint32_t val); You prefer something like this? -- Mindaugas ___ 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: BPF_MISC+BPF_COP and BPF_COPX
Darren Reed darr...@netbsd.org wrote: You do not have to use it. I get no choice - it is in the kernel by default. There is no default coprocessor. Here is your choice: do not call bpf_set_cop(9) and those instructions will effectively be NOPs. ... No. It's not about calling a function, it is about proving the BPF program is correct and secure. BPF today is essentially assembly language operations that are all easily tested and verified. ... On 8/08/2013 5:18 AM, Joerg Sonnenberger wrote: On Thu, Aug 08, 2013 at 01:35:24AM +1000, Darren Reed wrote: A BPF program is an entity that can be verified as correct from a security perspective.It is also self contained and requires no external references in order to understand. How is this relevant for the discussion? It is important to understand what BPF is before making changes to it. It is *your* understanding with a premise you just came up. I do not think that your premise is universally accepted. The reason why we have bpf_validate(9) is to ensure that the byte-code cannot cause any harm to the kernel (whether it is an infinite loop, a crash or any other security vulnerability), because it is passed from the *user*. The fundamental difference is that the coprocessor comes from the *kernel*. We tend to trust that the kernel is not self-harming and compilers do constructive job. We cannot validate that (unless you want to challenge Turing's halting problem), but the point being is that we do not need to. Then add BPF instructions to manipulate address sets (add, remove, lookup) and pick a datastore to use to support it. How is that more useful than the proposal? Actually, add/remove are not instructions for the BPF language, only lookup. Add, remove, etc, would be handled in the usual manner. How is that more useful? You contradict yourself here. It still calls some external reference which you are arguing against. The capability of the opcodes is programmed into the BPF program, not through some external reference. A BPF program generated on Linux is just as valid as on Solaris or NetBSD. Whilst that may be meaningless because nobody copies BPF programs around (in byte code format), this would open a door on developing specialised behaviour for my platform that isn't present elsewhere. This then diminishes the value of BPF. When I was thinking of BPF_COP/BPF_COPX, I was thinking of MIPS. The capability of the opcodes does not have to be programmed into the BPF program. You still have a core set of BPF instructions which will work everywhere and there is a reason why we have BPF_MISC. I can understand the concern about platforms implementing different behaviour, but your proposal of adding an instruction for every specific operation is not going to help. It is a question of agreement (hence CC freebsd-net). -- Mindaugas ___ 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: how calculate the number of ip addresses in a range?
Le Thu, 8 Aug 2013 11:34:22 +0430, s m sam.gh1...@gmail.com a écrit : hello guys, i have a question about ip addresses. i know my question is not related to freebsd but i googled a lot and found nothing useful and don't know where i should ask my question. i want to know how can i calculate the number of ip addresses in a range? for example if i have 192.0.0.1 192.100.255.254 with mask 8, how many ip addresses are available in this range? is there any formula to calculate the number of ip addresses for any range? i have 192.0.0.1 192.100.255.254 with mask 8 This doesn't mean anything ? There are few tools to deal with ip addresses, you can study the code : python: IPy https://github.com/haypo/python-ipy perl : ipcalc: /usr/ports/net-mgmt/ipcalc ... Basically, an ip address is just a number. IPy associates also a prefix length in an IP object. So it can represent a host or a network which is nice. Regards. ___ 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: BPF_MISC+BPF_COP and BPF_COPX
On 8/08/2013 9:14 PM, Mindaugas Rasiukevicius wrote: Darren Reed darr...@netbsd.org wrote: You do not have to use it. I get no choice - it is in the kernel by default. There is no default coprocessor. Here is your choice: do not call bpf_set_cop(9) and those instructions will effectively be NOPs. Anyone with the required privileges to run tcpdump can set this coprocessor. ... No. It's not about calling a function, it is about proving the BPF program is correct and secure. BPF today is essentially assembly language operations that are all easily tested and verified. ... On 8/08/2013 5:18 AM, Joerg Sonnenberger wrote: On Thu, Aug 08, 2013 at 01:35:24AM +1000, Darren Reed wrote: A BPF program is an entity that can be verified as correct from a security perspective.It is also self contained and requires no external references in order to understand. How is this relevant for the discussion? It is important to understand what BPF is before making changes to it. ... The reason why we have bpf_validate(9) is to ensure that the byte-code cannot cause any harm to the kernel (whether it is an infinite loop, a crash or any other security vulnerability), because it is passed from the *user*. At present it is impossible for there to be an infinite loop because it always branches/jumps forward, thus preventing looping behaviour. It is this very strictness that makes BPF work and worthwhile. Without that, it may as well be Java or some other byte code language. Then add BPF instructions to manipulate address sets (add, remove, lookup) and pick a datastore to use to support it. How is that more useful than the proposal? Actually, add/remove are not instructions for the BPF language, only lookup. Add, remove, etc, would be handled in the usual manner. How is that more useful? You contradict yourself here. It still calls some external reference which you are arguing against. Ok, I'll un-contradict myself: it shouldn't be possible for BPF to consist of mneumonics that are function calls that work on the packet rather than operations on the registers/memory. If I implied that this was ok then I was wrong. Have you presented why this approach that you've embarked on is required and others do not work? Is it trying to deal with a limitation/problem in npf? Darren ___ 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: BPF_MISC+BPF_COP and BPF_COPX
Darren Reed darr...@netbsd.org wrote: On 8/08/2013 9:14 PM, Mindaugas Rasiukevicius wrote: Darren Reed darr...@netbsd.org wrote: You do not have to use it. I get no choice - it is in the kernel by default. There is no default coprocessor. Here is your choice: do not call bpf_set_cop(9) and those instructions will effectively be NOPs. Anyone with the required privileges to run tcpdump can set this coprocessor. You got it wrong. Sorry if I was not clear, I will try to clarify it again: each BPF user (caller) in the *kernel* would have its own *independent* context (state). Some user(s) might set and use the coprocessor, while the others (kernel part providing /dev/bpf) might not use it. They would not affect each other. There is no way to set the coprocessor at the userlevel (with libpcap or whatever) if there is no kernel code supporting that. It is important to understand what BPF is before making changes to it. ... The reason why we have bpf_validate(9) is to ensure that the byte-code cannot cause any harm to the kernel (whether it is an infinite loop, a crash or any other security vulnerability), because it is passed from the *user*. At present it is impossible for there to be an infinite loop because it always branches/jumps forward, thus preventing looping behaviour. It is this very strictness that makes BPF work and worthwhile. Without that, it may as well be Java or some other byte code language. What kind of strictness are you talking about? Previously you were talking about security, now about the capability of the BPF byte-code. The coprocessor support provides offloading capability. It does not add looping capability and no - it does not change BPF to be Turing-complete. If your point was that we should not consider improvements and conserve the instruction set from 80s, then we simply disagree. :) Actually, add/remove are not instructions for the BPF language, only lookup. Add, remove, etc, would be handled in the usual manner. How is that more useful? You contradict yourself here. It still calls some external reference which you are arguing against. Ok, I'll un-contradict myself: it shouldn't be possible for BPF to consist of mneumonics that are function calls that work on the packet rather than operations on the registers/memory. If I implied that this was ok then I was wrong. Can you provide a justification for this? Have you presented why this approach that you've embarked on is required and others do not work? It provides way much greater flexibility, or rather - it provides the flexibility, while your solution does not. Is it trying to deal with a limitation/problem in npf? Not at all. This is to avoid code duplication. It is BPF which has a limitation and BPF_COP is a clean way (design wise) to address it. -- Mindaugas ___ 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: how calculate the number of ip addresses in a range?
Try subcalc, it's in ports. -- Jason Hellenthal Inbox: jhellent...@dataix.net Voice: +1 (616) 953-0176 JJH48-ARIN On Aug 8, 2013, at 7:30, Patrick Lamaiziere patf...@davenulle.org wrote: Le Thu, 8 Aug 2013 11:34:22 +0430, s m sam.gh1...@gmail.com a écrit : hello guys, i have a question about ip addresses. i know my question is not related to freebsd but i googled a lot and found nothing useful and don't know where i should ask my question. i want to know how can i calculate the number of ip addresses in a range? for example if i have 192.0.0.1 192.100.255.254 with mask 8, how many ip addresses are available in this range? is there any formula to calculate the number of ip addresses for any range? i have 192.0.0.1 192.100.255.254 with mask 8 This doesn't mean anything ? There are few tools to deal with ip addresses, you can study the code : python: IPy https://github.com/haypo/python-ipy perl : ipcalc: /usr/ports/net-mgmt/ipcalc ... Basically, an ip address is just a number. IPy associates also a prefix length in an IP object. So it can represent a host or a network which is nice. Regards. ___ 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 smime.p7s Description: S/MIME cryptographic signature
Re: how calculate the number of ip addresses in a range?
On Thu, Aug 8, 2013, at 10:44, Jason Hellenthal wrote: Try subcalc, it's in ports. I always kept ipcalc installed, but it looks like there's another called sipcalc, too. I'll have to check these out myself and see if any have merits over each other. ___ 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: how calculate the number of ip addresses in a range?
pkg_add -r ipsc ipsc -gch 10.80.128.0/27 Network class:A Network mask: 255.0.0.0 Network mask (hex): FF00 Network address: 10.80.128.0 Subnet bits: 19 Max subnets: 524288 Full subnet mask: 255.255.255.224 Full subnet mask (hex): FFE0 Host bits:5 Addresses per subnet: 32 Bit map: ...sssh IP address: 10.80.128.0 Hexadecimal IP address: A508000 Host allocation range:10.80.128.1 - 10.80.128.30 Full subnet mask: 255.255.255.224 Subnet mask: 0.255.255.224 Subnet ID:0.80.128.0 Network ID: 10.0.0.0 Host ID: 0.80.128.0 CIDR notation:10.0.0.0 /27 Supernet max: 0 Cisco wildcard: 0.0.0.31 Classful network: 10.0.0.0 /8 Route/Mask: 10.0.0.0 / 255.255.255.224 Hexadecimal route/mask: A00/ FFE0 On Thu, Aug 8, 2013 at 8:54 AM, Mark Felder f...@freebsd.org wrote: On Thu, Aug 8, 2013, at 10:44, Jason Hellenthal wrote: Try subcalc, it's in ports. I always kept ipcalc installed, but it looks like there's another called sipcalc, too. I'll have to check these out myself and see if any have merits over each other. ___ 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: [net] protecting interfaces from races between control and data ?
On Aug 7, 2013, at 10:16 PM, Warner Losh i...@bsdimp.com wrote:
On Aug 5, 2013, at 11:20 AM, Adrian Chadd wrote:
.. and I bet it's not a design pattern, and this is total conjecture on my
part:
* the original drivers weren't SMP safe;
* noone really sat down and figured out how to correctly synchronise
all of this stuff;
* people did the minimum amount of work to keep the driver from
immediately crashing, but didn't really think things through at a
larger scale.
Almost every driver is this way Luigi. :-)
Most of the drivers in the three don't support hardware that performs well
enough for this to be a problem. :) Any driver that's still around from the
pre-locking days can easily saturate the lines (or the hardware) on today's
(and even yesterday's hardware).
All the rest have come up with different ways to cope…
Not really.
So the typical pattern is:
foo_rxeof()
{
….
FOO_UNLOCK(sc);
ifp-if_input(ifp, m);
FOO_LOCK(sc);
….
}
Grepping for an approximation of this pattern:
[nflx1] ~/svn/head/sys/dev% grep -r -B 5 if_input * | grep -i UNLOCK | cut -d
'/' -f 1
ae
age
alc
ale
an
an
bce
bfe
bge
bm
cadence
cas
cas
dc
de
e1000
e1000
e1000
ed
ep
et
ex
fe
fxp
gem
gxemul
hme
ie
ixgb
ixgbe
ixgbe
jme
le
le
lge
mge
msk
msk
my
nfe
nfe
nge
nve
pcn
pdq
re
sbni
sf
sge
sis
sk
sk
sn
snc
ste
stge
ti
tl
tsec
tx
txp
usb
usb
vge
virtio
vr
vte
vx
wb
wl
xe
xl
Sure a lot of these are very legacy. But there's a lot in here's that are not.
bge, bce, e1000, ixgbe, virtio, etc, probably more that I'm not catching in
this quick pass.
Scott
___
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: how calculate the number of ip addresses in a range?
hello guys, i have a question about ip addresses. i know my question is not related to freebsd but i googled a lot and found nothing useful and don't know where i should ask my question. i want to know how can i calculate the number of ip addresses in a range? for example if i have 192.0.0.1 192.100.255.254 with mask 8, how many ip addresses are available in this range? is there any formula to calculate the number of ip addresses for any range? i'm confusing about it. please help me to clear my mind. thanks in advance, SAM Aside from many ports available in the ports/net* categories that provide calculators, and such. You can use an online version @: http://ultimatedns.net/netcalc HTH --chris ___ 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: how calculate the number of ip addresses in a range?
On Thu, Aug 08, 2013 at 08:55:38AM -0700 I heard the voice of Michael Sierchio, and lo! it spake thus: pkg_add -r ipsc For another, there's a cidrcalc program installed by devel/libcidr (full disclosure: of which I'm the author) that does similar things: % cidrcalc -bs 10.80.128.35/27 Address: 10.80.128.35 Netmask: 255.255.255.224 (/27) BinAddr: 1010 0101 1000 00100011 10 80 128 35 BinMask: 1110 255 255 255 224 Wildcard: 0.0.0.31 Network: 10.80.128.32/27 Broadcast: 10.80.128.63 Hosts: 10.80.128.33 - 10.80.128.62 NumHosts: 30 Supernet: 10.80.128.0/26 Subnets: 10.80.128.32/28 10.80.128.48/28 -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ 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: how calculate the number of ip addresses in a range?
On Thu, Aug 8, 2013 at 2:46 PM, Matthew D. Fuller fulle...@over-yonder.net wrote: On Thu, Aug 08, 2013 at 08:55:38AM -0700 I heard the voice of Michael Sierchio, and lo! it spake thus: pkg_add -r ipsc For another, there's a cidrcalc program installed by devel/libcidr (full disclosure: of which I'm the author) that does similar things I still suspect he was asking for somebody to do his homework for him. A third party tool doesn't work for that. He needs the math for it. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV UTF-8: for when a ' just won\342\200\231t do. brueffer ZFS must be the bacon of file systems. everything's better with ZFS ___ 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: [net] protecting interfaces from races between control and data ?
.. and it's not just about saturate the port with traffic. It's also about what happens if I shut down the MAC whilst I'm in the process of programming in new RX/TX descriptors? The ath(4) driver had a spectacular behaviour where if you mess things up the wrong way it will quite happily DMA crap all over the memory of your running system, leading to quite hilarious bugs. -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: [net] protecting interfaces from races between control and data ?
Yup, it's an incredibly unsafe pattern. It also leads to the pattern where auxiliary processing is handed off to a taskqueue, which then interleaves the lock ownership with the ithread and produces out-of-order packet reception. Scott On Aug 8, 2013, at 5:18 PM, Adrian Chadd adr...@freebsd.org wrote: .. and it's not just about saturate the port with traffic. It's also about what happens if I shut down the MAC whilst I'm in the process of programming in new RX/TX descriptors? The ath(4) driver had a spectacular behaviour where if you mess things up the wrong way it will quite happily DMA crap all over the memory of your running system, leading to quite hilarious bugs. -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: kern/181135: [netmap] [patch] sys/dev/netmap patch for Linux compatibility
Old Synopsis: sys/dev/netmap patch for Linux compatibility New Synopsis: [netmap] [patch] sys/dev/netmap patch for Linux compatibility Responsible-Changed-From-To: freebsd-bugs-freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Aug 9 01:26:45 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=181135 ___ 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: kern/181131: [netmap] [patch] sys/dev/netmap memory allocation improvement
Old Synopsis: sys/dev/netmap memory allocation improvement New Synopsis: [netmap] [patch] sys/dev/netmap memory allocation improvement Responsible-Changed-From-To: freebsd-bugs-freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Aug 9 01:29:19 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=181131 ___ 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
