> So I got set up with Vonage VoIP, which I am really excited to have, but
> I am having a heck of a time getting it set up behind my FreeBSD box.
>
> My network configuration is as follows:
> Cable modem --> FreeBSD 5.2.1-R (ipf/ipnat) --> 8-port D-Link Switch -->
> Internal network
>
> The Von
This is all pretty interesting, though it seems like you'd only
need to cobble together a shell script to do what you're after.
The ifconfig command seems happy to tell you the MAC address of
a specified interface.. It seems like an already present prototyping
environment for this type of configu
> On Sun, May 23, 2004 at 07:37:37PM -0400, Louis A. Mamakos wrote:
> > >>> This could be the first step towards teaching rc.conf about something like
> > >>> network_interfaces_rename="hw-00:03:0d:08:dc:a7 sis0int"
> > >> I don't
> Well actually you should discuss the necessity of the changes in ifconfig with
> the author of the original posting :) What I proposed was just middle way
> between what he proposed and what I did. I mean if somebody is changing
> ifconfig anyway that way would be easier to implement. However pe
> In article
>[EMAIL PROTECTED]>
> you write:
> >
> >On Sat, 16 Dec 2000, Alfred Perlstein wrote:
> >
> >> I think M_DONTWAIT is fine as it was, and M_TRYWAIT instead of M_TRY_WAIT.
> >>
> >> Leaving it as M_DONTWAIT should reduce the delta by quite a bit and
> >> M_TRYWAIT vs M_TRY_WAIT because
> Poul-Henning Kamp <[EMAIL PROTECTED]> wrote:
> >I may not have caught the drift here, but if you send meta-data
> >across the net, wouldn't some kind of authentication be needed?
>
> Yes, It must be. This is probably the next-in-thread request for
> comments/suggestions. I'm still not sure if t
The crock in these trunking schemes is all the trouble and effort expended
to avoid re-ordering frames across the trunk bundle. This is why you
see things like the hashing techniques so that an individual flow of
traffic doesn't get reordered because it always is serialized over the
a single pat
> > So that the same logic applies to TCP packets as well. Currently, we
> > can send a TCP packet with a checksum of 0, which is legal. Of possible
> > interest is that Linux doesn't do this; they alwyas send a non-zero
> > checksum in the TCP case, if a checksum was computed.
> >
> Hmm, but
> On Wed, Mar 07, 2001 at 09:40:34AM -0500, Louis A. Mamakos wrote:
> >
> > > > So that the same logic applies to TCP packets as well. Currently, we
> > > > can send a TCP packet with a checksum of 0, which is legal. Of possible
> > > > interest is
> In two's complement arithmetics, yes. What matters here is how the
> the real checkers are implemented. For BSD-derived implementations,
> this does not matter. I don't know if others really exist. RFC 1624
> is pretty clear on this topic. The usual Internet principle is in place
> (from R
> while I'm not intimately familiar with PPPoE, it's obvious that
> it cannot use IP addresses for its underlying communication; it must use
> MAC addresses and have its own DLC mechanism. This suggests that its
> packets probably have a unique Ethertype. Does anyone know offhand what
> that
> > The way the network is set up, not all of the nodes can
> > hear one another, but all can communicate with the hub. Using PPPoE
> > makes the traffic go through the hub without subnetting (which
> > would require reconfiguring many machines, some of which I do
> > not administer). Could you s
> I've never thought that the 4 bytes of overhead per PPPoE frame was
> terribly inefficient, compared to, say, IP-in-IP with another 20 byte
> IP header. But I'm certainly not arguing that a choice of technology
> be made on simply the number of bytes on the wire; there are other
> things to c
>
> Should I be able to "tcpdump -i gif0"? tcpdump indicates it's listening
> on gif0 but I never capture anything.
>
> My gif's look like this:
> gif0: flags=8091 mtu 1440
> inet 10.3.1.1 --> 10.3.2.1 netmask 0x
> physical address inet 207.76.205.83 --> 207.76.205.115
>
>
> my preference is to dropp support for multi-destination mode from
> gif(4), as the multi-destination behavior is violating network layering
> (rt_gateway is in inner header, and gif(4) multi-destination mode
> uses it to determinte outer header).
There's certainly a b
> > this traffic is holding my ppp connection open
> > for hours at a time, is there any way to filter
> > this out
> >
> > I tried adding `set filter in 0 deny igmp`
> > to my ppp.conf config but then I couldn't do external
> > DNS.
>
> Try
>
> set filter alive 0 deny igmp
> set filter a
> /usr/sbin/ancontrol -i an0 -s 2
.
.
.
> The second issue is the biggest one. For some reason I have high
> latency when pinging my gateway. With the wireless card, I get ping
> replies between 200 and 400 ms while I get around 10 ms with a regular
> ethernet car
> > Even if it takes 0 ns to do a route lookup, a stock freebsd
> > system can't do more than 20K ~ 100K pkts/second due to many
> > bottlenecks. In a hardware accelrated router one can easily
> > do 10M route lookups *without* using an expensive & power
> > hungry fancy CAM. But they may be wo
>
> I agree with your comment that FCAK is only a retransmission algorithm and
> many papers recommends that FACK+SACK improves the performance for
> long-delay network (for more information look at 1996 SIGCOMM paper).
Most of the hair in a TCP implementation is "only" the retransmission
algori
Doesn't this behavior need to be on a per-interface basis? I'm wondering
if a single sysctl is sufficient to get the desired effect.
louie
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
> On Wed, Dec 05, 2001 at 01:35:52PM -0500, Louis A. Mamakos wrote:
> > Doesn't this behavior need to be on a per-interface basis? I'm wondering
> > if a single sysctl is sufficient to get the desired effect.
> >
> No, we want ARP table to stay intact no ma
Juniper had (and probably does) a version of JunOS that runs on PC
platforms with Ethernet (and some others) network interfaces. I've
used this in the past for some interoperability testing and qualification
activities.
However, JunOS and the routing protocol stack represent intellectual
proper
The problem, of course, is that tunnel-mode IPSEC is too coarse a
mechanism to implement security policy for some people. Imagine if
you will that you're using IPSEC in an "extranet" situation; that is,
to secure communication between two different parties. Perhaps between
you and your supplier
We put the session ID in the protocol so that you could support
multiple simultanous PPP sessions from the same host over a
single Ethernet (bridged ethernet over DSL in most cases) to
the session concentrator platform.
Imagine one PPP session for Internet access; perhaps another for
some corpo
Is the server filtering out ICMP traffic with ipfw or something?
> Alexey Luckyanchikov wrote:
>
>
> > 14:06:48.477578 server.7 > client.1371: . 1437:2897(1460) ack 10001 win 65535 (DF)
>(ttl 64, id 25428, len 1500)
> > ^^^
> > Server send packet with size
>
> just a PS reminder that you need to put the IP/ports in network byte
> order. appropriate htonl() and htons() must be used if the the values
> are not already in network byte order. You may get away with not doing
> this on a Sparc (or Alpha?) because of their endian is network byte
> order.
> Attila Nagy wrote:
> >
> > Hello,
> >
> > > I developped a basic implementation of MPLS over Ethernet in the FreeBSD
> > > Environment! If someone is interested in my code just e.mail me!
> > Great! Although I do not have the devices to test this, it is very
> > nice to hear that. I think the
> If there is no kind of software involved on the forwarding plane
> then I don't know how the control plane can communicate via ethernet
> with the line cards... The internal communication in the router is
> via ethernet.
To be clear, "forwarding plane" to me means the machinary which
causes pa
> Hi,
>
> Could someone tell me if there is a way to build a VPN(like) tunnel from
> a FreeBSD machine acting as a VPN gateway to another machine acting as
> another VPN gateway using normal IP packets that have only their data
> payload encrypted. Of course there would have to be a way to setup
>
> Yes, I can attest to this an I belive it is actually the case on both
> -current and -releng4 that disabling newreno improves TCP performance.
>
> I belive running an X11 application or scp(1) over a wavelan is a very
> good test-bed for this issue.
>
> --
> Poul-Henning Kamp | UNIX
> > I do not permit any ICMP packages...
> > What could I do to solve this?Permit ICMP 520?
Sigh, and this is why Path MTU discovery is broken on the Internet. You
know, that ICMP stuff actually gets used for useful purposes. Just
blocking it completely has implications that you should think a
> Does freeBSD support ftp for a multicast address?
It would be really hard for any OS to support FTP to a multicast
address, as TCP doesn't work with multicast addresses. FTP uses
TCP as the transport protocol for it's control connection and the
data connection that's used to move data between
>
> My goal is to create an ipfw rule that stops normal syn floods by blocking
> ALL syn packets that have no MSS set.
>
> My understanding is that there is no legitimate packet that is a SYN and
> has no MSS, and further, most of the kiddie tools in existence for syn
> flooding do indeed send sy
The problem is in your test program; you're calling inet_ntoa() twice
in your printf() invocation, and the second call to inet_ntoa() overwrites
the static buffer that's returned.
louie
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailma
34 matches
Mail list logo
