[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-users] Re: [lwip] RFC: ARP (timing) behaviour
From: |
Scott Robinson |
Subject: |
[lwip-users] Re: [lwip] RFC: ARP (timing) behaviour |
Date: |
Thu, 09 Jan 2003 00:48:03 -0000 |
--k1lZvvs/B4yU6o8G
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
10 seconds is still far too much. Will it continue queuing if, during those
10 seconds, another packet is sent?
I'm seeing a pattern where once it delayed, it stays delayed.
Scott.
* address@hidden translated into ASCII [Thu, Nov 14, 2002 at 12:1=
3:13AM +0100][<address@hidden>]
> Hello Scott,
>=20
> > While on the subject of ARP, what is the maximum it'll delay the packet?
> >=20
> > It seems that I've had UDP packets delayed from transmission for up to =
60
> > seconds. Seem familiar? ;-)
> >
> Hmm, this may have been a result of the old etharp.c code. Currently, que=
ued
> packets are dropped from pending ARP entries on every call to etharp_tmr(=
),
> as can be seen
> in the code below. So, at most 10 seconds if you follow the advice:
> =20
> Leon.
>=20
> If you call etharp_tmr() every 10 seconds,
> {
> ...
> ++ctime;
> /* remove expired entries from the ARP table */
> ...
>=20
> } else if((arp_table[i].state =3D=3D ETHARP_STATE_PENDING) &&
> (ctime - arp_table[i].ctime >=3D ARP_MAXPENDING)) {
> arp_table[i].state =3D ETHARP_STATE_EMPTY;
> /* remove any queued packet */
> pbuf_free(arp_table[i].p); =20
> arp_table[i].p =3D NULL;
> }
>=20
> --=20
> +++ GMX - Mail, Messaging & more http://www.gmx.net +++
> NEU: Mit GMX ins Internet. Rund um die Uhr f?r 1 ct/ Min. surfen!
>=20
> [This message was sent through the lwip discussion list.]
--=20
http://quadhome.com/ - Personal webpage
tranzoa.net - Firewall
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GAT dpu s: a--- C++ UL+++ P++ L+++ E- W++ N++ o+ K++ w++=20
O M V(-) PS+ PE Y+ PGP+++ t@ 5 X- R- tv(-) b++++ DI++++ D+=20
G e* h! r* y=20
------END GEEK CODE BLOCK------
--k1lZvvs/B4yU6o8G
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)
iEYEARECAAYFAj3TFLQACgkQ+1+mlYgeODeLSwCgtVmHSDSZ7nAItxyq4hZMsUiO
6wcAoMJRsFVKxKI2+kbwzEksPQoYUkII
=PDY3
-----END PGP SIGNATURE-----
--k1lZvvs/B4yU6o8G--
[This message was sent through the lwip discussion list.]