Hi everybody,
I'm doing some testing and want to move one ethernet cable between
multiple interfaces in the same box.
As soon as I move the cable I get:
Mar 19 01:32:22 develop /kernel: arp: 192.168.1.1 is on sis0 but
got reply from 00:80:ad:81:fc:d4 on sis1
I have tried to do " arp -d -a" an
Maybe something to do with IP addresses on interfaces?
-M
Soren Kristensen wrote:
>
> Hi everybody,
>
> I'm doing some testing and want to move one ethernet cable between
> multiple interfaces in the same box.
>
> As soon as I move the cable I get:
>
> Mar 19 01:32:22 develop /kernel: arp: 1
Hi there,
Once upon a time I ran into several bugs in the FreeBSD networking
code. Being a humble FreeBSD user, I started send-pr and wrote bug
reports including detailed descriptions and fixes on all of them,
but they still seem to remain unnoticed by the responsible.
We are heading to a new re
> Hi there,
>
> Once upon a time I ran into several bugs in the FreeBSD networking
> code. Being a humble FreeBSD user, I started send-pr and wrote bug
> reports including detailed descriptions and fixes on all of them,
> but they still seem to remain unnoticed by the responsible.
> We are headi
On Mon, Mar 19, 2001 at 06:32:44PM +0100, Luigi Rizzo wrote:
>
> > We are heading to a new release, but the bugs are still there.
> >
> > Could a commiter do me a favor and take a look at the following reports:
>
> which are about ??? you know we are better at parsing text strings than
> number
< said:
> if_delmulti() (net/if.c) does not notify a corresponding interface
> driver when a _link-layer_ multicast group is being left.
> There is a mtod() without a prior m_pullup() in netinet/if_ether.c.
> The system might be likely to crash sometimes...
> The vlan driver don't update byte/p
Just a follow up with more information
The status do change to active when I move the cable from one
interface to another, so there is physical connection.
Output from "ifconfig -a":
sis0: flags=8843 mtu 1500
inet 192.168.1.20 netmask 0xff00 broadcast
192.168.1.255
inet6
Hi Lars,
I do flush the arp cache on the other end, a windows 98se box
(192.168.1.4). And after pinging the FreeBSD box from the Windows
box, the Windows box arp cache is updated to the correct
interface.
Also, I get the errors during the pings, so the FreeBSD box
receives *something* on the sis
Bill,
I have tested the port aggregation module on a BayStack 450-12, although I'm
not sure the BayStack trunking is compatible with Etherchannel. I'm using a
four port Adaptec in my FreeBSD 4.3-BETA system. After some attempts (I have
never configured trunking on a BayStack) I had two links up,
Soren Kristensen wrote:
> I have tried to do " arp -d -a" and "route flush" and even tried
> to reboot, but somehow freebsd keep remembering where it saw the
> IP for the first time and refuse to change it's mind
Are you doing this on both ends? Flushing the local ARP cache doesn't help
you i
Actually, I think quoting PR#s is a more than acceptable way of
pointing things out. They're very easy to look up for anyone (and
committers get the extra advantage of using query-pr on freefall) and
it sure beats wearing one's fingers out by entering the same
information over and over again.
We
Hello Garrett,
On Mon, Mar 19, 2001 at 01:08:32PM -0500, Garrett Wollman wrote:
>
> I have taken a look at all of these and your suggested fixes appear to
> be correct in concept. I have not tested any of them, however.
As for me, I can see a fixed system work perfectly for months. It
was an un
> Actually, I think quoting PR#s is a more than acceptable way of
> pointing things out. They're very easy to look up for anyone (and
> committers get the extra advantage of using query-pr on freefall) and
IF you have connectivity while you are reading, which is my whole
point. The one big advan
On Tue, 20 Mar 2001, Luigi Rizzo wrote:
> > Actually, I think quoting PR#s is a more than acceptable way of
> > pointing things out. They're very easy to look up for anyone (and
> > committers get the extra advantage of using query-pr on freefall) and
>
> IF you have connectivity while you are
On Tue, Mar 20, 2001 at 01:04:48AM +0100, Luigi Rizzo wrote:
> > Actually, I think quoting PR#s is a more than acceptable way of
> > pointing things out. They're very easy to look up for anyone (and
> > committers get the extra advantage of using query-pr on freefall) and
>
> IF you have connect
Dear sir,
While going thought the module ipv6_input.c i found that the code for
ipv6_forward function is missing. It was commented that for now we will
discard the packet. In the ipv6_forward function m_free() was callled & the
m_buf is freed. Kindly mail me if this is implemented some where else
Hi ,
can any one help me with this.
how is the tcp/ip stack running.is it a single process? or is it
running as multiple processes.
pls tell me if i do ps -aef which is the process concerned with the
tcp/ip stack implementation.
As far as i know inetd daemon has daemons for applications like
tel
* Vishwanath P <[EMAIL PROTECTED]> [010319 20:48] wrote:
> Hi ,
>
> can any one help me with this.
> how is the tcp/ip stack running.is it a single process? or is it
> running as multiple processes.
> pls tell me if i do ps -aef which is the process concerned with the
> tcp/ip stack implementatio
Hi,
I modified the FreeBSD 4.2 kernel and occasionally the kernel crashes. How
can I determine the line of code that caused the crash? I tried addr2line
with the fault address but that didn't work. Thanks in advance!!
Regards,
Virdi
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscr
On Sun, Mar 18, 2001 at 07:42:10PM -0800, Julian Elischer scribbled:
| Wes Peters wrote:
| > It struck me last night that if you want to load-balance between two ISPs,
| > you could simply pick a bit in the address and use it to select one or the
Buy a Layer >4 switch for your home DSL+cable mode
>While going thought the module ipv6_input.c i found that the code for
>ipv6_forward function is missing. It was commented that for now we will
>discard the packet. In the ipv6_forward function m_free() was callled & t=
>he
>m_buf is freed. Kindly mail me if this is implemented some where else or
Brent Voltz writes:
> I have an ADSL line that uses PPPoE encapsulation. I've been trying to get
> a PPTP connection working with FreeBSD 4.2 release on the same box that
> connects to the ADSL.
>
> The process is as follows:
>
> 1) Bring up PPPoE connection, using either user-space PPP or MPD.
Dear Sir,
I found that the packets to be sent are queued in a interface queue by the
ipv6_output function if the interface is busy. My doubt is whether the packets
are sent through the interfaces by separate processes.
regards
ravi prasad.
_
* ravi prasad <[EMAIL PROTECTED]> [010319 22:49] wrote:
> Dear Sir,
> I found that the packets to be sent are queued in a interface queue by the
> ipv6_output function if the interface is busy. My doubt is whether the packets
> are sent through the interfaces by separate processes.
They are sent
Hi,
My system is having an internal interface, named sf0 and external sf3.
I have cvsup'ed 4.3-BETA as of 16 march and have copied the /usr/src/etc/rc*
files to /etc.
In rc.network the invocation of ipfilter is now at the beginning to support
IPFILTER_DEFAULT_BLOCK. When my system reboots it ha
25 matches
Mail list logo
