Alan Garfield wrote:
Peter Jeremy wrote:
Given that we are effectivly dealing with a shared memory block, how
does the SP now when the server has finished writing and vice versa?
Is jnet's handling of multiple mbufs making the SP think there are
multiple packets?
D'oh! /me slaps forehead
I wo
Peter Jeremy wrote:
Given that we are effectivly dealing with a shared memory block, how
does the SP now when the server has finished writing and vice versa?
Is jnet's handling of multiple mbufs making the SP think there are
multiple packets?
D'oh! /me slaps forehead
I wondereded what the NAK
On Wed, Apr 25, 2007 at 07:37:06AM +1000, Peter Jeremy wrote:
> On 2007-Apr-23 18:54:30 +0400, Yar Tikhiy <[EMAIL PROTECTED]> wrote:
> >Perhaps the bug is triggered when the outgoing packet consists of
> >multiple mbufs.
>
> Given that we are effectivly dealing with a shared memory block, how
> do
On 2007-Apr-23 18:54:30 +0400, Yar Tikhiy <[EMAIL PROTECTED]> wrote:
>Perhaps the bug is triggered when the outgoing packet consists of
>multiple mbufs.
Given that we are effectivly dealing with a shared memory block, how
does the SP now when the server has finished writing and vice versa?
Is jnet
On Mon, Apr 23, 2007 at 10:24:46AM +1000, Alan Garfield wrote:
> On Sat, 2007-04-21 at 03:36 +0400, Yar Tikhiy wrote:
>
> > >
> > > Disconnecting: Corrupted MAC on input.
> > >
> >
> > That looks like data corruption happening when TCP segments and/or
> > IP packets become relatively la
On Sat, 2007-04-21 at 03:36 +0400, Yar Tikhiy wrote:
> >
> > Disconnecting: Corrupted MAC on input.
> >
>
> That looks like data corruption happening when TCP segments and/or
> IP packets become relatively large, i.e., approach or reach the mtu
> limit.
The reply looks disturbing from
Yar Tikhiy wrote:
Disconnecting: Corrupted MAC on input.
That looks like data corruption happening when TCP segments and/or
IP packets become relatively large, i.e., approach or reach the mtu
limit.
Indeed that would appear to be the case.
I'm sure it's something to do with how I
On Sat, Apr 21, 2007 at 12:03:25AM +1000, Alan Garfield wrote:
> On Thu, 2007-04-19 at 21:53 +0400, Yar Tikhiy wrote:
>
> > 1. Ping the Linux side with packets close to the MTU in size (ping
> > -s), use different data patterns (ping -p), see with tcpdump -X if
> > the data gets damaged.
>
> Yeah
On Thu, 2007-04-19 at 21:53 +0400, Yar Tikhiy wrote:
> 1. Ping the Linux side with packets close to the MTU in size (ping
> -s), use different data patterns (ping -p), see with tcpdump -X if
> the data gets damaged.
Yeah I figured out. I wasn't handling mbuf chains properly so a bit of
the packet
On 2007-Apr-19 23:50:00 +1000, Alan Garfield <[EMAIL PROTECTED]> wrote:
>debug1: Local version string SSH-2.0-OpenSSH_3.4p1
>debug1: SSH2_MSG_KEXINIT sent
>d475 078f 7eae aef6
>Disconnecting: Bad packet length -730527857.
>debug1: Calling cleanup 0x1001fc68(0x0)
>localhost $
'Bad packet length'
On Thu, Apr 19, 2007 at 11:50:00PM +1000, Alan Garfield wrote:
[...]
>
> BUT! Now I have a weird bug.
>
> SSH on the SP whinges about :-
>
>
> localhost $ ssh -v 169.254.101.3
> OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090703f
> debug1: Reading configuration data /etc/ssh/ssh_config
On Thu, 2007-04-19 at 15:38 +0400, Yar Tikhiy wrote:
> inet 127.0.0.1 netmask 0xff00
> > jnet0: flags=845 mtu 241
> > inet 169.254.101.3 netmask 0x
> > ether 00:09:3d:00:00:03
>
> Note that jnet0 has no broadcast address. That should be wrong for
> an Ethern
On Thu, Apr 19, 2007 at 07:51:13PM +1000, Alan Garfield wrote:
[...]
>
> > > I beginning to think the ARP issue is a symptom not the cause. The cause
> > > may well be something is wrong with my initialisation of the output
> > > queue and my handling of the de-queueing packets. I've looked at man
On Thu, 2007-04-19 at 13:38 +0400, Yar Tikhiy wrote:
>
> >
> > // Configure the structure for the device
> > ifp->if_softc = sc;
> > if_initname(ifp, device_get_name(dev), device_get_unit(dev));
> >
> > // Function pointers
> > ifp->if_start
On Thu, Apr 19, 2007 at 06:54:23PM +1000, Alan Garfield wrote:
> On Thu, 2007-04-19 at 11:35 +0400, Yar Tikhiy wrote:
>
> > > ... and I get these ARP errors.
> > >
> > >
> > > jnet0: port 0xa8,0xae-0xaf irq 19 on
> > > acpi0
> > > jnet0: Ethernet address: 00:09:3d:00:00:03
> > > jnet0: jnet
On Thu, 2007-04-19 at 11:35 +0400, Yar Tikhiy wrote:
> > ... and I get these ARP errors.
> >
> >
> > jnet0: port 0xa8,0xae-0xaf irq 19 on
> > acpi0
> > jnet0: Ethernet address: 00:09:3d:00:00:03
> > jnet0: jnet_start_locked() called.
> > jnet0: m == 0.
> > jnet0: RTM_ADD.
> > arplookup 169
On Thu, Apr 19, 2007 at 11:56:54AM +1000, Alan Garfield wrote:
> On Wed, 2007-04-18 at 16:06 +0400, Yar Tikhiy wrote:
> >
> > > I just want an idea of the structures involved, and what I need to
> > > implement to intercept and injecting a fake MAC so my buffer driver can
> > > communicate with t
On Wed, 2007-04-18 at 19:56 +0100, Bruce M. Simpson wrote:
> The ARP code is pretty well documented in TCP/IP Illustrated Volume 2
> and hasn't really significantly changed. Whilst I personally dislike how
> reentry happens in some of the paths, it works.
Might have to this book to my collecti
On Wed, 2007-04-18 at 16:06 +0400, Yar Tikhiy wrote:
>
> > I just want an idea of the structures involved, and what I need to
> > implement to intercept and injecting a fake MAC so my buffer driver can
> > communicate with the other side without ARP errors.
>
> Could you tell more details on the
Alan Garfield wrote:
Hi all!
One word HOW! :)
I've no clue what this FreeBSD ARP stuff is all about, there is little
or no documentation, there are 14 different sock_addr's which seem to
have a bazillion different fields, and I cannot output a simple debug
statement without getting 'error:
On Wed, Apr 18, 2007 at 11:50:09AM +1000, Alan Garfield wrote:
> Hi all!
>
> One word HOW! :)
>
> I've no clue what this FreeBSD ARP stuff is all about, there is little
> or no documentation, there are 14 different sock_addr's which seem to
> have a bazillion different fields, and I cannot ou
please, give us more info about the connection between ARP (address
resolution protocol) and rtentry/rtrequest.
about the debug information:
man 9 printf
man 9 log
On 4/18/07, Alan Garfield <[EMAIL PROTECTED]> wrote:
Hi all!
One word HOW! :)
I've no clue what this FreeBSD ARP stuff is all
Hi all!
One word HOW! :)
I've no clue what this FreeBSD ARP stuff is all about, there is little
or no documentation, there are 14 different sock_addr's which seem to
have a bazillion different fields, and I cannot output a simple debug
statement without getting 'error: dereferencing pointer t
23 matches
Mail list logo
