On Mon, 2007-07-30 at 22:32 -0400, Bill Sommerfeld wrote:
> Garrett left out the real motivation for my strong objection:
>
> primarily:
> - UDP's special handling of the zeros checksum means that packets which
> checksum to 0 can be undetectably corrupted downstream unless the udp
> checksum is
Garrett left out the real motivation for my strong objection:
primarily:
- UDP's special handling of the zeros checksum means that packets which
checksum to 0 can be undetectably corrupted downstream unless the udp
checksum is correctly encoded as all-ones (the one's complement -0).
secondarily:
> There appears to be a fetal implementation or ND Proxy in ip_ndp.c (see
> references to NCE_F_PROXY) whose origins are a bit of a mystery. The
> flag and the code surrounding it (currently the dangling NDF_PROXY_ON and
> NDF_PROXY_OFF flags for the SIOCLIFSETND ioctl, and twiddling the
As part of the effort to putback a fix for 6587116 (which impacts
checksum offload on my recent hme for cases where the packet is too
small), the code reviewer (Bill Sommerfeld) asked about the difference
between the handling of TCP vs. UDP checksums. (Specifically what
happens when the checksum c
[replacing all the opensolaris groups that I dropped by mistake]
On (07/30/07 14:12), Garrett D'Amore wrote:
>
> On Mon, 2007-07-30 at 16:38 -0400, [EMAIL PROTECTED] wrote:
> > On (07/26/07 11:17), Garrett D'Amore wrote:
> > > peer=>nonetxrxboth
> > > adv
> > >none n
There appears to be a fetal implementation or ND Proxy in ip_ndp.c (see
references to NCE_F_PROXY) whose origins are a bit of a mystery. The
flag and the code surrounding it (currently the dangling NDF_PROXY_ON and
NDF_PROXY_OFF flags for the SIOCLIFSETND ioctl, and twiddling the
override bit
Fred Medlin wrote:
> I've developed a driver/application based on the pfhooks api on x86
> hardware using 5.11 snv_55b.
>
> Now, trying to port to Sparc hardware, I'm seeing SunOS 5.10
> Generic_118833-18. There is no /usr/include/sys/neti.h header.
> Are there other options besides 1) installin
James Carlson wrote:
> Garrett D'Amore writes:
>
>> This creates a problem, as Nemo/GLDv3 does not provide a way for NICs to
>> advertise whether or not they can support such VLAN frames.
>>
>
> For what it's worth, GLDv2 had such a mechanism (gldm_send_tagged),
> described in PSARRC 2002/
Garrett D'Amore writes:
> This creates a problem, as Nemo/GLDv3 does not provide a way for NICs to
> advertise whether or not they can support such VLAN frames.
For what it's worth, GLDv2 had such a mechanism (gldm_send_tagged),
described in PSARRC 2002/721.
--
James Carlson, Solaris Networking
Sebastien Roy writes:
> > 2. customer wants to use /etc/ppp/ip-up script, but in the case there
> > are multiple PPP peers, does he need to use multiple ip-up files ? ( He
> > wants configure each ppp link differently )
>
> This can be done by having the ip-up script differentiate between the
>
Judith Zhu wrote:
> I want to query about PPP configuration (solaris 10)
>
> 1. Is there any way to set a delay in chat script ?
> for example, AT command is run and then after several seconds's delay ,
> ATDT is run.
The chat(1M) man page states that the \d escape sequence results in a one
se
Bart Smaalders wrote:
> Kacheong's design involves either a call to port_getn or a call to
> select/poll., followed by a call to his new function, recvfrom_list():
A correction, Stephen Uhler proposed this.
> while (1) {
> select(...) /* get list of active sockets */
> recvfrom_lis
Hi all,
I want to query about PPP configuration (solaris 10)
1. Is there any way to set a delay in chat script ?
for example, AT command is run and then after several seconds's delay ,
ATDT is run.
2. customer wants to use /etc/ppp/ip-up script, but in the case there
are multiple PPP peers,
Joost Mulders wrote:
>> We want to leave ieee802.3 beneath the scene
>>
> I agree that drivers must maintain a "well defined" set of statistics.
> ieee802.3(5) is a good starting point for now but the set probable will
> need expansion in the future. For example, 10Gb is not in ieee802.3(5)
> We want to leave ieee802.3 beneath the scene
I agree that drivers must maintain a "well defined" set of statistics.
ieee802.3(5) is a good starting point for now but the set probable will
need expansion in the future. For example, 10Gb is not in ieee802.3(5)
and also the max size of jumbo fram
Garrett D'Amore wrote:
> Cathy Zhou wrote:
>> Garrett D'Amore wrote:
>>> One of the problems I've found recently is that some certain legacy
>>> devices that should be able to support GLDv3 might not be able to
>>> support full size VLAN frames.
>>>
>>> This creates a problem, as Nemo/GLDv3 does
Guys:
Could we conclude we could implements pause control like below?
We want to leave ieee802.3 beneath the scene while providing user with a
UI which makes more sense.
/* We use 0/1 to represent "off/on" respectively. */
Default: accept_pause = send_pause = 1;
UI: accept_pause = 1, send_paus
Cathy Zhou wrote:
> Garrett D'Amore wrote:
>> One of the problems I've found recently is that some certain legacy
>> devices that should be able to support GLDv3 might not be able to
>> support full size VLAN frames.
>>
>> This creates a problem, as Nemo/GLDv3 does not provide a way for NICs
>>
18 matches
Mail list logo
