Dear ,
We are so glad to hear that you are also in the field of presentation equipment.
This is Redins from Hongbao which is focused on Interactive Displaying
Equipment. We have different Interactive Touch Screen, Digital Signage, etc.
If you have more question, we would like to give you more info
On 5/08/2013 5:12 AM, Mindaugas Rasiukevicius wrote:
> Hello,
>
> 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.
A BPF program is an entity that can be veri
On 8/08/2013 3:55 AM, Mindaugas Rasiukevicius wrote:
> Darren Reed 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
On 8/08/2013 9:14 PM, Mindaugas Rasiukevicius wrote:
> Darren Reed 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_se
On 9/08/2013 12:17 AM, Mindaugas Rasiukevicius wrote:
> Darren Reed wrote:
>> On 8/08/2013 9:14 PM, Mindaugas Rasiukevicius wrote:
>>> Darren Reed wrote:
>>>>>
>>>>> You do not have to use it.
>>>>
>>>> I get no c
On 10/08/2013 7:23 AM, Matt Thomas wrote:
> ...
> The possibility of the COP/COPX functions doing bad things is over wrought.
> It makes the assumption of avoiding BPF and then coding everything is safer
> than using BPF and COP/COPX functions.
Depends on what you mean by "bad things."
Thus fa
Mindaugas Rasiukevicius wrote:
Hi,
OK, to summarise what has been discussed:
- Problem
There is a need to perform more complex operations from the BPF program.
Currently, there is no (practical) way to do that from the byte-code.
Such functionality is useful for the packet filters or other com
On Thu, Aug 29, 2013, at 05:27 PM, Mindaugas Rasiukevicius wrote:
> Darren Reed wrote:
> > Mindaugas Rasiukevicius wrote:
> > > Hi,
> > >
> > > OK, to summarise what has been discussed:
> > >
> > > - Problem
> > >
> > >
Look, if you're going to appeal to core to approve changes for
committing then don't bother posting them to tech-net or any other list
because it is quite clear that you are not interested in feedback, only
people to rubber-stamp your ideas.
All of which to say is that I'm sorry I bothered replyin
I've been tracking down some problems with FreeBSD's sending
of TCP packets and seem to have come to the conclusion that
in FreeBSD 8.2-RELEASE, when the system is working with a
TCP connection that has a moderate delay in it, FreeBSD's
TCP ignores the other end telling it that the window size
is n
Jason Hellenthal wrote:
On Sat, Mar 31, 2012 at 01:22:27AM +1100, Darren Reed wrote:
I've been tracking down some problems with FreeBSD's sending
of TCP packets and seem to have come to the conclusion that
in FreeBSD 8.2-RELEASE, when the system is working with a
TCP connection
Andre Oppermann wrote:
On 30.03.2012 16:22, Darren Reed wrote:
I've been tracking down some problems with FreeBSD's sending
of TCP packets and seem to have come to the conclusion that
in FreeBSD 8.2-RELEASE, when the system is working with a
TCP connection that has a moderate d
Darren Reed wrote:
Andre Oppermann wrote:
On 30.03.2012 16:22, Darren Reed wrote:
I've been tracking down some problems with FreeBSD's sending
of TCP packets and seem to have come to the conclusion that
in FreeBSD 8.2-RELEASE, when the system is working with a
TCP connection
Andre,
Your changes bring it closer to working correctly with a
small change: rather than "tiwin > tp->snd_wnd", it should
be "tiwin != tp->snd_wnd". In this trace, the remote end
has set a window scale factor of 5 during connection
establishment.
The same change should be made in the if() a few
On 3/04/2012 11:45 PM, Andre Oppermann wrote:
> On 01.04.2012 09:27, Darren Reed wrote:
>> Andre,
>>
>> Your changes bring it closer to working correctly with a
>> small change: rather than "tiwin > tp->snd_wnd", it should
>> be "tiwin != tp
On 4/04/2012 3:17 AM, Andre Oppermann wrote:
> On 03.04.2012 17:38, Darren Reed wrote:
>> On 3/04/2012 11:45 PM, Andre Oppermann wrote:
>>> It's the other way around. remote.ssh is sending old data
>>> which freebsd82.62922 has already ack'ed. The ses
On 4/04/2012 3:17 AM, Andre Oppermann wrote:
> On 03.04.2012 17:38, Darren Reed wrote:
>> On 3/04/2012 11:45 PM, Andre Oppermann wrote:
>>> It's the other way around. remote.ssh is sending old data
>>> which freebsd82.62922 has already ack'ed. The ses
Andre Oppermann wrote:
On 03.04.2012 17:38, Darren Reed wrote:
On 3/04/2012 11:45 PM, Andre Oppermann wrote:
On 01.04.2012 09:27, Darren Reed wrote:
The problem here is that it only tracks the window size as
it grows, not as it shrinks. Thus the remote end setting its
window size to 0 is
I've run into a rather strange problem with rsh on FreeBSD 9.0
where rsh seems to become a fork bomb.
How or why this happens, I do not know. If I run it from the
command line with a shell, it behaves perfectly normal. Even
inside $() with pdksh. But when I put it in my script...
What does the pr
It would seem that setting $RSH to "rsh" is the cause
of my problem and that rcmd(3) cannot deal with RSH
pointing to itself.
I've filed a PR on this (possibly duplicate) but the
email with the PR# is taking its time.
Darren
___
freebsd-net@freebsd.org
I've looked through the list of network interfaces that are
supported with FreeBSD and none seem to meet my needs. What
I want is a network interface that I can configure up in
jail A with address 10.1.1.1 and for which I can configure
a mate in jail B with the address 10.2.2.2 and use the
network
On 28/05/2012 11:45 PM, Nikos Vassiliadis wrote:
> On 5/28/2012 1:37 PM, Darren Reed wrote:
>> I've looked through the list of network interfaces that are
>> supported with FreeBSD and none seem to meet my needs. What
>> I want is a network interface that I can conf
On 29/05/2012 9:56 AM, Julian Elischer wrote:
> On 5/28/12 7:14 AM, Darren Reed wrote:
>> On 28/05/2012 11:45 PM, Nikos Vassiliadis wrote:
>>> On 5/28/2012 1:37 PM, Darren Reed wrote:
>>>> I've looked through the list of network interfaces that are
>>>&g
Is there any reason that this patch hasn't been applied
to -current? I've just run into this and I can't believe
that it still exists, given that it falls into the "low
hanging fruit" category. I'll note that if it wasn't for
subversion, I'd be doing a commit rather than an email.
Darren
On 3/06/2012 5:11 AM, Bjoern A. Zeeb wrote:
>
> On 2. Jun 2012, at 15:53 , Darren Reed wrote:
>
>> Is there any reason that this patch hasn't been applied
>> to -current? I've just run into this and I can't believe
>> that it still exists, given th
To echo comments made on tech-net for NetBSD...
---
As much as I dislike the patch you created, I can't see any other way
to elegantly solve the problem. The reason that I don't like the change
is that it seems silly to have to put the packet in two different mbufs
after having put it all in one.
> Quoting from pfil(9)
>
> When a filter is invoked, the packet appears just as if it ``came off the
> wire''. That is, all protocol fields are in network byte order. [...]
pfil(9) is already out of date with respect to FreeBSD as
FreeBSD passes both ip_len and ip_off through in host byte
or
The problem is that you have a port range of 0 in an
ipnat.conf line. Quick solution is to ensure that all
ipnat.conf lines specify a range of ports of greater than 0.
Otherwise patch below applies.
Darren
--- /tmp/ip_nat.c.orig 2012-06-06 04:31:31.0 +1000
+++ /tmp/ip_nat.c 2012-0
In IPFilter, the "map-block" ipnat rule serves exactly the
purpose that you are looking for. It provides address
translation of network addresses for N:M and uses ports
to multiplex them in.
Thus a /16 can be nat'd to a /8 with the other 8 bits
used in the port number.
The results of the NAT'd pa
David Duchscher wrote:
On Jun 5, 2012, at 3:29 PM, Darren Reed wrote:
In IPFilter, the "map-block" ipnat rule serves exactly the
purpose that you are looking for. It provides address
translation of network addresses for N:M and uses ports
to multiplex them in.
Thus a /16 can be nat
Andre Oppermann wrote:
On 03.04.2012 17:38, Darren Reed wrote:
On 3/04/2012 11:45 PM, Andre Oppermann wrote:
On 01.04.2012 09:27, Darren Reed wrote:
The problem here is that it only tracks the window size as
it grows, not as it shrinks. Thus the remote end setting its
window size to 0 is
Kip Macy wrote:
My ethng branch supports multiple rx and tx queues.
-Kip
What are your plans for how we use/manage/interact with the mutiple
rx/tx queues?
Darren
On 9/22/07, Jack Vogel <[EMAIL PROTECTED]> wrote:
> Our newest E1000 nic, the 82575, and the Oplin 10G hardware are capabl
ue pair for ssh.
Maybe I want to dedicate a tx/rx queue pair for my web server.
etc.
Darren
Of course, if the transmit path through the network stack isn't enabling
concurrency, a bottleneck there won't be an issue.
Louis Mamakos
Just something else to consider..
On Sep 23, 2007, a
Max Laier wrote:
On Friday 23 November 2007, Robert Watson wrote:
> On Fri, 23 Nov 2007, Max Laier wrote:
> > attached is a diff to switch the pfil(9) subsystem to rmlocks, which
> > are more suited for the task. I'd like some exposure before doing
> > the switch, but I don't expect any fallout.
Max Laier wrote:
On Sunday 25 November 2007, Darren Reed wrote:
> Max Laier wrote:
> > On Friday 23 November 2007, Robert Watson wrote:
> > > On Fri, 23 Nov 2007, Max Laier wrote:
> > > > attached is a diff to switch the pfil(9) subsystem to rmlocks,
> > &g
Max Laier wrote:
On Sunday 25 November 2007, Darren Reed wrote:
> Max Laier wrote:
> > On Sunday 25 November 2007, Darren Reed wrote:
> > > Max Laier wrote:
> > > > On Friday 23 November 2007, Robert Watson wrote:
> > > > > On Fri, 23 Nov 2007, Max L
In some mail from Baldur Gislason, sie said:
>
> ipfw is in no way related to the linux firewalls (ipfwadm, ipchains or
> iptables). It is a specially designed firewall for FreeBSD. It isn't
> dependent on ipf, it has it's own in-kernel mechanism. It has a totally
> different syntax. Why FreeBS
In some email I received from Guy Harris, sie wrote:
> On Sep 8, 2004, at 2:26 AM, Bruce M Simpson wrote:
>
> > Here's a patch against 5.3 to add a per-instance switch which allows
> > the user to specify if captured packets should be timestamped (and,
> > if so, whether microtime() or the faster
In some mail from Wes Peters, sie said:
>
> Kris Kennaway wrote:
> >
> > On Thu, Apr 12, 2001 at 12:40:32AM -0500, Mike Silbersack wrote:
> >
> > > Each IP packet sent has with it a 16-bit ID. The numbers must remain
> > > unique over a short period of time so fragmentation can work properly.
In some mail from Kris Kennaway, sie said:
>
>
> --rwEMma7ioTxnRzrJ
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Mon, Apr 16, 2001 at 02:03:11AM -0700, Kris Kennaway wrote:
>
> > Here's a patch ported from OpenB
In some mail from Kris Kennaway, sie said:
>
> Surely that can't work since the purpose of that field is for received
> packet ordering (unless I'm wrong, I'm not an IPv4 guru and only
> skimmed the RFC), and what's ordered in network order isn't ordered in
> host order.
It is not used by the re
In some mail from Kris Kennaway, sie said:
>
>
> --TYecfFk8j8mZq+dy
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Tue, Apr 17, 2001 at 04:36:15AM +1000, Darren Reed wrote:
>
> > You should optimize it for mod being 2^n
In some mail from Julian Elischer, sie said:
>
> Darren Reed wrote:
> >
> > In some mail from Kris Kennaway, sie said:
> > >
> > >
> > > --rwEMma7ioTxnRzrJ
> > > Content-Type: text/plain; charset=us-ascii
> > > Content-Dispos
In some mail from Alfred Perlstein, sie said:
>
> * Rodney W. Grimes <[EMAIL PROTECTED]> [010417 10:37] wrote:
> > > * Darren Reed <[EMAIL PROTECTED]> [010417 04:29] wrote:
> > > > In some mail from Julian Elischer, sie said:
> > > > >
&
In some mail from Jason DiCioccio, sie said:
>
> From: "Darren Reed" <[EMAIL PROTECTED]>
> Subject: Re: non-random IP IDs
>
>
> > How long has your box been up ? How many changes to the system config
> > have been made since then ? If you&
In some email I received from Gunther Schadow, sie wrote:
[...]
> As an added benefit, the two network interfaces tun0 and fxp0 allow
> me to cope with the limited power of IPFILTER's NAT rules (as compared
> to IPFW).
What is so limiting about NAT in IPFilter ?
AFAIK, apart from packet matchi
In some email I received from Gunther Schadow, sie wrote:
> Gunther Schadow wrote:
> [snip]
>
> to make things even more complicated, we also have the
> berkeley packet filter (BPF) mechanism. Heck! How could
> so many things evolve that all do essentially the same
> thing? The interesting
In some email I received from Julian Elischer, sie wrote:
[Charset iso-8859-2 unsupported, filtering to ASCII...]
> Darren Reed wrote:
> >
> > In some email I received from Gunther Schadow, sie wrote:
> > > Gunther Schadow wrote:
> > > [snip]
> > >
>
In some email I received from Gunther Schadow, sie wrote:
[...]
> I am just completely amazed about how many things there are that
> basically do very similar jobs, like packet filtering/classifying.
> While in general diversity is good, it is also a problem for the
> developers and users of the *
In some email I received from Jason R Thorpe, sie wrote:
> On Thu, May 03, 2001 at 08:30:55AM +1000, Darren Reed wrote:
>
> > IPFilter 4.0 will, as part of its general increase in kernel bloat,
> > let you use BPF expressions for matching. There are other things
>
>
In some email I received from Jason R Thorpe, sie wrote:
> On Thu, May 03, 2001 at 10:01:18AM +1000, Darren Reed wrote:
>
> > > BPF "expressions" are literally BPF bytecodes.
> >
> > Well, one of the goals of IPFilter is it can parse (as rules) a
Hi,
So i've been implementing some new features in ipfilter, whether
or not they make it a 5.0, I'm not sure...maybe a few people can
let me know what they think about that..
So what are these new features?
There are 3 new commands for ipnat.conf:
rewrite - change both source and address fields
A project I'm looking to do in my spare time at Sun is to
create a library that provides access to some of the
more useful ioctls supported by IPFilter. The problem
with relying on ioctls is that if the data structures passed
through change then often everything needs to be
recompiled.
I current
I think this is getting absurd/stupid.
What do we have 3 firewalls for in FreeBSD if people are going to
add knobs like this that just duplicate that behaviour ?
Is there something lacking in all of those firewalls that make
this necessary ?
Are they all too hard to use ?
Do they all impact per
rk around for
> this?
I can see how this possible could work -- unless popper doesn't mind about
invalid argument.
Anyways, tcpd and inetd should complain (via log files) if there are
problems. (Also, be sure to tell inetd with a HUP when you update its
configs.)
Good luck,
Jeremy C. Reed
cgi?pr=67598 (closed)
http://www.freebsd.org/cgi/query-pr.cgi?pr=68445 (closed)
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=859964+0+/usr/local/www/db/text/2006/freebsd-current/20060108.freebsd-current
Jeremy C. Reed
p.s. I don't have physical access to this hardware, so I am get
hat the driver would not attempt auto
> negotiation. If the option is not required - lose it - otherwise try
> adding a media option to your ifconfig.
Thanks. We'll give that a try. (I now recall that I had to do that with
bge on some other hardware over a year ago.)
Jeremy C. Reed
___
use.
Or run named on your FreeBSD box and use it.
Have a look at the handbook:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-dns.html
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-configfiles.html
Jeremy C. Reed
echo '9,J8HD,[EMAIL PRO
58 matches
Mail list logo
