Re: em(4) patch for test
Here is my second round of my non scientific benchmarking and tests, I hope this is useful. I been having fun benchmarking these machines but I am starting to get sick of it as well :) but I find it important to know that things are going to work right when they are launched to do their real work. The final results look good after patching and running ab tests I was unable to get errors out of netstat -i output, even when grilling the server-C machine to a rather high load. Test 1 (Non patched) netperf test, non patched machines. load results below with top -S, no Ierrs or Oerrs. A> /usr/local/netperf/netperf -l 60 -H server-C -t TCP_STREAM -i 10,2 -I 99,5 -- -m 4096 -s 57344 -S 57344 Server-C load snap shot last pid: 1644; load averages: 0.94, 0.48, 0.23 up 0+06:30:41 12:29:59 239 processes: 7 running, 130 sleeping, 102 waiting CPU states: 0.5% user, 0.0% nice, 2.3% system, 9.4% interrupt, 87.9% idle Mem: 125M Active, 1160M Inact, 83M Wired, 208K Cache, 112M Buf, 1893M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 13 root1 171 52 0K 8K CPU1 0 0:00 99.02% idle: cpu1 14 root1 171 52 0K 8K RUN0 386:01 98.97% idle: cpu0 12 root1 171 52 0K 8K CPU2 2 389:02 97.75% idle: cpu2 11 root1 171 52 0K 8K RUN3 385:10 61.87% idle: cpu3 62 root1 -68 -187 0K 8K WAIT 3 1:03 14.16% irq64: em0 112 root1 -44 -163 0K 8K CPU2 3 1:35 11.23% swi1: net 1644 root1 40 1640K 1016K sbwait 3 0:09 7.25% netserver 30 root1 -64 -183 0K 8K CPU3 3 0:19 2.15% irq16: uhci0 Server-A load snap shot last pid: 1550; load averages: 0.34, 0.32, 0.21 up 0+07:28:38 12:41:33 134 processes: 3 running, 52 sleeping, 78 waiting, 1 lock CPU states: 0.8% user, 0.0% nice, 10.2% system, 42.1% interrupt, 47.0% idle Mem: 13M Active, 27M Inact, 70M Wired, 24K Cache, 213M Buf, 1810M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZERES STATETIME WCPU COMMAND 11 root1 171 52 0K16K RUN438:50 54.98% idle 83 root1 -44 -163 0K16K WAIT 2:41 17.63% swi1: net 59 root1 -68 -187 0K16K RUN 1:48 11.23% irq64: em2 1547 root1 40 3812K 1356K sbwait 0:17 8.84% netperf 27 root1 -68 -187 0K16K *Giant 0:51 2.78% irq16: em0 uhci0 Test 2 (Non patched) On the Apache beat up test with: A> 'ab -k -n 25500 -c 900 http://server-c/338kbyte.file' You can see some error output from netstat -i on both machines, C> netstat -i | egrep 'Name|em0.*Link' NameMtu Network Address Ipkts IerrsOpkts Oerrs Coll em01500 00:14:22:12:4c:03 85133828 2079 63248162 0 0 top highest load. last pid: 2170; load averages: 35.56, 16.54, 8.52 up 0+07:28:47 13:28:05 1182 processes:125 running, 954 sleeping, 103 waiting CPU states: 5.4% user, 0.0% nice, 37.2% system, 32.4% interrupt, 25.0% idle Mem: 372M Active, 1161M Inact, 131M Wired, 208K Cache, 112M Buf, 1595M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 13 root1 171 52 0K 8K CPU1 0 0:00 100.00% idle: cpu1 62 root1 -68 -187 0K 8K WAIT 3 5:57 89.79% irq64: em0 30 root1 -64 -183 0K 8K CPU0 0 2:11 36.08% irq16: uhci0 12 root1 171 52 0K 8K RUN2 439:16 2.98% idle: cpu2 14 root1 171 52 0K 8K RUN0 435:36 2.98% idle: cpu0 11 root1 171 52 0K 8K RUN3 430:35 2.98% idle: cpu3 2146 root1 -80 4060K 2088K piperd 2 0:01 0.15% rotatelogs 129 root1 200 0K 8K syncer 0 0:08 0.05% syncer 112 root1 -44 -163 0K 8K WAIT 0 4:50 0.00% swi1: net 110 root1 -32 -151 0K 8K WAIT 3 1:05 0.00% swi4: clock sio 2149 www66 1130 44476K 31276K RUN3 0:08 0.00% httpd Server-A netstat and highest top. (non patched) A> netstat -i | egrep 'em2.*Link|Name' NameMtu Network Address Ipkts IerrsOpkts Oerrs Coll em21500 00:14:22:15:ff:8e 61005124 690 84620697 0 0 last pid: 1698; load averages: 0.65, 0.29, 0.13 up 0+08:15:10 13:28:05 136 processes: 6 running, 53 sleeping, 76 waiting, 1 lock CPU states: 3.4% user, 0.0% nice, 58.6% system, 32.0% interrupt, 6.0
Re: em(4) patch for test
On Sun, Oct 23, 2005 at 05:24:02PM +1000, Michael VInce wrote: M> Here is my second round of my non scientific benchmarking and tests, I M> hope this is useful. M> I been having fun benchmarking these machines but I am starting to get M> sick of it as well :) but I find it important to know that things are M> going to work right when they are launched to do their real work. M> M> The final results look good after patching and running ab tests I was M> unable to get errors out of netstat -i output, even when grilling the M> server-C machine to a rather high load. Again big thanks! I must note that increased speed in your test isn't a luck. If we get rid of errors, that are lost packets, surely TCP speed will increase. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
in_cksum() for ip packets with multiple mbufs
i come across this unusual problem. i changed the ip_tos field of the struct ip and computed the checksum by using in_cksum(). when the packet uses only one mbuf the computed checksum is ok but when the packet uses more than one mbuf then the computed checksum is wrong. eg. pinging with payload less than 1470 bytes is ok but with payload greater than 1480 bytes does not work. (the error being bad checksum --that i knew by capturing network packets by ethereal) is it a real problem or i have made some mistake. i put the code before the if_output() in the ip_output() function. help !! kamal __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: in_cksum() for ip packets with multiple mbufs
On 2005-10-23 01:30, kamal kc <[EMAIL PROTECTED]> wrote: > i come across this unusual problem. > > i changed the ip_tos field of the struct ip and computed the checksum > by using in_cksum(). > > when the packet uses only one mbuf the computed checksum is ok but > when the packet uses more than one mbuf then the computed checksum is > wrong. Note that the IP header contains a checksum of the IP header only. A common mistake is to calculate the checksum of data too, which results in an invalid IP header checksum. > eg. pinging with payload less than 1470 bytes is ok but with payload > greater than 1480 bytes does not work. (the error being bad checksum > --that i knew by capturing network packets by ethereal) > > is it a real problem or i have made some mistake. > > i put the code before the if_output() in the ip_output() function. Show us the diff, if possible :) ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPSec tcp session stalling ( me too ) ...
On Sat, Oct 22, 2005 at 10:01:46PM +0100, Volker wrote: [] > Is anybody else here with deep TCP + IPSec knowledge able to get a look > into this? Any known issues? Is there anything I might also check out? > Is there a 64k limit with IPSec? :( IPSec works, even for huge datas sessions: I'm using it every day, and a lot of my customers would already have complained about it if there were such problems ! :-) As I said before, this really looks like problems I regulary see, when the ESP packets will have to be fragmented (ESP adds an encapsulation level). Use a lower MTU on your traffic endpoints or play with the TCPMSS value on one gate (at least pf can be configured to do that), and ensure that there is no more fragmented ESP packets between the IPSec gates (of course, TCPMSS solution is easier to set up, but will only work for TCP sessions...). ESP maximum overhead is 4 (SPI) + 4 (seq number) + 255 (padding) + 2 (pad len + next header) + 96 (SHA-1-96 auth value, see RFC 2404) bytes, but usually, overhead will be around 100 bytes (including authentication, but ESP should really not be used without authentication), so setting up for internal hosts an MTU of (Public Interface MTU) - 150 should be enough, without really decreasing global performances. You should also have better performances when this will be fixed. Yvan. -- NETASQ - Secure Internet Connectivity http://www.netasq.com ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: in_cksum() for ip packets with multiple mbufs
> > i changed the ip_tos field of the struct ip and
> computed the checksum
> > by using in_cksum().
> >
> > when the packet uses only one mbuf the computed
> checksum is ok but
> > when the packet uses more than one mbuf then the
> computed checksum is
> > wrong.
>
> Note that the IP header contains a checksum of the
> IP header only.
>
> A common mistake is to calculate the checksum of
> data too, which results
> in an invalid IP header checksum.
ok i made this mistake to calculate the checksum
over the entire IP payload.
i corrected this and used the ip_hl field :::
/* the argument m is the (struct mbuf *) that
* contains the packet data
*/
void copy_the_memorybuffer(struct mbuf **m)
{
struct mbuf *mbuf_pointer=*m;
struct mbuf **next_packet;
next_packet=&mbuf_pointer;
struct ip *my_ip_hdr;
my_ip_hdr=mtod((*next_packet),struct ip *);
my_ip_hdr->ip_tos=64;
my_ip_hdr->ip_sum=0;
my_ip_hdr->ip_sum=
in_cksum((*next_packet),(my_ip_hdr->ip_hl<<2));
...
}
but still it doesn't seem to work. and the problem
is still there.
i am really confused ..
> > eg. pinging with payload less than 1470 bytes is
> ok but with payload
> > greater than 1480 bytes does not work. (the error
> being bad checksum
> > --that i knew by capturing network packets by
> ethereal)
> >
> > is it a real problem or i have made some mistake.
> >
> > i put the code before the if_output() in the
> ip_output() function.
>
> Show us the diff, if possible :)
sorry i did not understand what to show here.
does it mean to show the packet data captured by
the ethereal..
thanks kamal
__
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: in_cksum() for ip packets with multiple mbufs
On 2005-10-23 04:13, kamal kc <[EMAIL PROTECTED]> wrote:
> /* the argument m is the (struct mbuf *) that
> * contains the packet data
> */
>
> void copy_the_memorybuffer(struct mbuf **m)
> {
>struct mbuf *mbuf_pointer=*m;
>struct mbuf **next_packet;
>
>next_packet=&mbuf_pointer;
>
>struct ip *my_ip_hdr;
>my_ip_hdr=mtod((*next_packet),struct ip *);
>my_ip_hdr->ip_tos=64;
>my_ip_hdr->ip_sum=0;
>
>my_ip_hdr->ip_sum=
>in_cksum((*next_packet),(my_ip_hdr->ip_hl<<2));
> ...
> }
Why all this pointer fun? How do you know that it's safe to dereference
`m' when you do:
struct mbuf *mbuf_pointer=*m;
Why are you dereferencing `m' once to obtain mbuf_pointer and then
taking the address of that to obtain next_packet, when you could
just do:
next_packet = m;
There are also several other problems with copy_the_memorybuffer() as
it's written above:
- It's considered bad style to mix declarations and code the way you
have done above
- It is probably better to return the copy of the mbuf you're
fiddling with, instead of modifying in place a parameter of the
function.
- If you are not *REALLY* copying the data of the mbuf, then
the name of copy_the_memorybuffer() is very confusing.
- What is the magic constant 64 that is assigned to ip_tos?
What you probably want to do is something like:
void
ip_set_type_of_service(struct mbuf *m)
{
struct ip *iph;
assert(m != NULL);
iph = mtod(m, struct ip *);
iph->ip_tos = IPTOS_PREC_IMMEDIATE;
iph->ip_sum = 0;
iph->ip_sum = in_cksum((uint16_t *)iph, iph->ip_hl << 2);
}
but that's not copying anything.
> but still it doesn't seem to work. and the problem
> is still there.
You have obviously made a lot of changes that we haven't seen yet.
Instead of posting snippets here and there, save a copy of the original
sources somewhere, then a copy of the new sources, and run diff(1) on
the two directories to extract *ALL* the changes.
$ cd /usr/src
$ diff -ruN src.old/ src/ > /tmp/patchfile
and put the patchfile somewhere online where we can have a look at all
the changes.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPSec tcp session stalling ( me too ) ...
Yvan, as far as I'm not totally wrong on the MTU issue, I've already checked that. On the other side, if it's an MTU issue, wouldn't the stream break at the first oversized packet? I mean the scp session is sending around 56k of data through the stream and then the session stalls. My gnetcat test setup was able to get somewhat around 64k of data through the tunnel before the session gets aborted. >From my view if it's an MTU issue it has to stall when the first 2, 3 or 4 kByte have been transmitted. Am I wrong? Also I already tried to play around with pf and set max-mss as low as 640 or 576 just for testing this. It didn't solve anything. As written in my first post of this thread, the gifX interface already has the lowest possible MTU (by default) of 1280. The underlaying interface (emX on hostA, ng0 on hostB) has an MTU of 1500 (emX) and 1492 (ng0). That should already give enough room (>200byte) for IPSec headers (as long as the whole path between both hosts does support an MTU of 1500). I'm currently in the process of switching to FAST_IPSEC on both machines and will repeat the test. It takes a bit longer as both machines are remote to me. Thanks for your help! Volker Yvan wrote: > > As I said before, this really looks like problems I regulary see, when > the ESP packets will have to be fragmented (ESP adds an encapsulation > level). > > Use a lower MTU on your traffic endpoints or play with the TCPMSS > value on one gate (at least pf can be configured to do that), and > ensure that there is no more fragmented ESP packets between the IPSec > gates (of course, TCPMSS solution is easier to set up, but will only > work for TCP sessions...). > > ESP maximum overhead is 4 (SPI) + 4 (seq number) + 255 (padding) + 2 > (pad len + next header) + 96 (SHA-1-96 auth value, see RFC 2404) > bytes, but usually, overhead will be around 100 bytes (including > authentication, but ESP should really not be used without > authentication), so setting up for internal hosts an MTU of (Public > Interface MTU) - 150 should be enough, without really decreasing > global performances. > > > You should also have better performances when this will be fixed. > > > > Yvan. > > -- NETASQ - Secure Internet Connectivity http://www.netasq.com ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Dependency between interfaces
On Sun, Oct 23, 2005 at 08:45:06AM +1300, Andrew Thompson wrote: > On Sat, Oct 22, 2005 at 01:37:35PM +, Wojciech A. Koszek wrote: > > On Fri, Oct 21, 2005 at 09:23:27AM +1300, Andrew Thompson wrote: > > > On Thu, Oct 20, 2005 at 08:20:34PM +, Wojciech A. Koszek wrote: > > > > Hello, > > > > > > > > [..] > > > > > > Is it still a problem or did you test on a pre r1.26 kernel? > > > > > > > Results from -CURRENT: I got panic if sk/rl modules are loaded, interfaces > > added to bridge0 and these drivers kldunload(8)ed: > > > > http://freebsd.czest.pl/dunstan/FreeBSD/bridge_rl.trace > > http://freebsd.czest.pl/dunstan/FreeBSD/bridge_sk.trace > > > > Can you please try this patch. Problem seems to be fixed with this patch. BTW, thanks for pjd@ for his help in tracking my weird panic. -- * Wojciech A. Koszek && [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PPPoE and Radius on 6.0RC1
- Original Message - From: "Marcin Jessa" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, October 21, 2005 8:55 PM Subject: Re: PPPoE and Radius on 6.0RC1 Thanks a lot. I recompiled my kernel with the netgraph options and set up the server with your configs. Besides from the fact that I only use my fxp0 in the tests. root 787 0.0 0.1 1256 796 ?? Ss2:41PM 0:00.02 /usr/libexec/pppoed -l PPPoE -P /var/run/pppoed.pid -p * fxp0 ok... but i would like to suggest your pppoe clients must be facing the ip less interface nic so that clients would not put static configuration on their side to defeat your pppoe configuration :-> I disabled radius as well adding username and password by hand. without radius does it worked? Although the radius itself works fine when I test it with radtest and user's credits. Just like before, nothing gets loged in ppp.log and the ppp process itself never gets started up by the pppoe daemon. does your radius server supports microsoft chap version 2? my config given to you only authenticates mschapv2... "on receipt of the SUCCESS indication, pppoed will execute exec /usr/sbin/ppp -direct label" - This part is not taking place actually pppoed did executed ppp ppp will exit immediately if it sees something wrong with its configuration, authentication and others... fooler. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em(4) patch for test
I just have to point out that below I made a statement that proved I should of gone to bed earlier instead of doing benchmarks :). The 901 http States and ssh state have nothing to do with each other as there on different pf rules. Mike Michael VInce wrote: I did watch the gateway (B) pf state table and did an ab test with and without pf running, I didn't see any difference in results when having pf running with stateful rules, ab's Time per requests stayed low and transfer rates stayed high. Most of the time the total states were exactly 900 (plus 1 for ssh session) which would make sense considering the 900 keep-alive concurrency level on the ab test. pftop output RULE ACTION DIR LOG Q IF PR K PKTSBYTES STATES MAX INFO 0 Pass In Q em2tcp M 37362067 1856847K 901 inet from any to server-c port = http ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: in_cksum() for ip packets with multiple mbufs
> > void copy_the_memorybuffer(struct mbuf **m)
> > {
> >struct mbuf *mbuf_pointer=*m;
> >struct mbuf **next_packet;
> >
> >next_packet=&mbuf_pointer;
> >
> >struct ip *my_ip_hdr;
> >my_ip_hdr=mtod((*next_packet),struct ip *);
> >my_ip_hdr->ip_tos=64;
> >my_ip_hdr->ip_sum=0;
> >
> >my_ip_hdr->ip_sum=
> >
> in_cksum((*next_packet),(my_ip_hdr->ip_hl<<2));
> > ...
> > }
>
> Why all this pointer fun? How do you know that it's
> safe to dereference
> `m' when you do:
>
> struct mbuf *mbuf_pointer=*m;
>
> Why are you dereferencing `m' once to obtain
> mbuf_pointer and then
> taking the address of that to obtain next_packet,
> when you could
> just do:
>
> next_packet = m;
>
> There are also several other problems with
> copy_the_memorybuffer() as
> it's written above:
>
> - It's considered bad style to mix declarations
> and code the way you
> have done above
>
> - It is probably better to return the copy of
> the mbuf you're
> fiddling with, instead of modifying in place a
> parameter of the
> function.
one thing i would like to ask?
does it make any difference if i free the mbuf 'm'
passed to if_output() and pass my own mbuf to
if_output.
is the original mbuf referenced by any
other pointers or global variables ??
i couldn't figure out much from the sources.
> - If you are not *REALLY* copying the data of
> the mbuf, then
> the name of copy_the_memorybuffer() is very
> confusing.
i didn't showed in the above code snippet but
actually i am copying the data contained in the
mbufs in a character array.
my purpose is to compress the data contained in
the ip packet
> - What is the magic constant 64 that is assigned
> to ip_tos?
that was just to see that i could actually modify
the ip header.
> What you probably want to do is something like:
>
> void
> ip_set_type_of_service(struct mbuf *m)
> {
> struct ip *iph;
>
> assert(m != NULL);
>
> iph = mtod(m, struct ip *);
> iph->ip_tos = IPTOS_PREC_IMMEDIATE;
> iph->ip_sum = 0;
> iph->ip_sum = in_cksum((uint16_t *)iph,
> iph->ip_hl << 2);
> }
thanks i will try this code and try to make the
code simpler next time.
> but that's not copying anything.
>
> > but still it doesn't seem to work. and the problem
> > is still there.
>
> You have obviously made a lot of changes that we
> haven't seen yet.
> Instead of posting snippets here and there, save a
> copy of the original
> sources somewhere, then a copy of the new sources,
> and run diff(1) on
> the two directories to extract *ALL* the changes.
>
> $ cd /usr/src
> $ diff -ruN src.old/ src/ > /tmp/patchfile
>
> and put the patchfile somewhere online where we can
> have a look at all
> the changes.
i am new to kernel sources and kernel programming and
thank you for informing me on the diff(1).
thanks to you that the problem was solved (i don't
know if it is completely ok). i found that
- i had made mistake in computing checksum.
earlier checksum was computed over the whole
dat
I may soon put up patchfiles on web.
thanks.
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: in_cksum() for ip packets with multiple mbufs
> > void copy_the_memorybuffer(struct mbuf **m)
> > {
> >struct mbuf *mbuf_pointer=*m;
> >struct mbuf **next_packet;
> >
> >next_packet=&mbuf_pointer;
> >
> >struct ip *my_ip_hdr;
> >my_ip_hdr=mtod((*next_packet),struct ip *);
> >my_ip_hdr->ip_tos=64;
> >my_ip_hdr->ip_sum=0;
> >
> >my_ip_hdr->ip_sum=
> >
> in_cksum((*next_packet),(my_ip_hdr->ip_hl<<2));
> > ...
> > }
>
> Why all this pointer fun? How do you know that it's
> safe to dereference
> `m' when you do:
>
> struct mbuf *mbuf_pointer=*m;
>
> Why are you dereferencing `m' once to obtain
> mbuf_pointer and then
> taking the address of that to obtain next_packet,
> when you could
> just do:
>
> next_packet = m;
>
> There are also several other problems with
> copy_the_memorybuffer() as
> it's written above:
>
> - It's considered bad style to mix declarations
> and code the way you
> have done above
>
> - It is probably better to return the copy of
> the mbuf you're
> fiddling with, instead of modifying in place a
> parameter of the
> function.
one thing i would like to ask?
does it make any difference if i free the mbuf 'm'
passed to if_output() and pass my own mbuf to
if_output.
is the original mbuf referenced by any
other pointers or global variables ??
i couldn't figure out much from the sources.
> - If you are not *REALLY* copying the data of
> the mbuf, then
> the name of copy_the_memorybuffer() is very
> confusing.
i didn't showed in the above code snippet but
actually i am copying the data contained in the
mbufs in a character array.
my purpose is to compress the data contained in
the ip packet
> - What is the magic constant 64 that is assigned
> to ip_tos?
that was just to see that i could actually modify
the ip header.
> What you probably want to do is something like:
>
> void
> ip_set_type_of_service(struct mbuf *m)
> {
> struct ip *iph;
>
> assert(m != NULL);
>
> iph = mtod(m, struct ip *);
> iph->ip_tos = IPTOS_PREC_IMMEDIATE;
> iph->ip_sum = 0;
> iph->ip_sum = in_cksum((uint16_t *)iph,
> iph->ip_hl << 2);
> }
thanks i will try this code and try to make the
code simpler next time.
> but that's not copying anything.
>
> > but still it doesn't seem to work. and the problem
> > is still there.
>
> You have obviously made a lot of changes that we
> haven't seen yet.
i did not put the whole code because i am a bit lazy
and the code is cumbersome. and i thought that
it was causing the problem.
> Instead of posting snippets here and there, save a
> copy of the original
> sources somewhere, then a copy of the new sources,
> and run diff(1) on
> the two directories to extract *ALL* the changes.
>
> $ cd /usr/src
> $ diff -ruN src.old/ src/ > /tmp/patchfile
>
> and put the patchfile somewhere online where we can
> have a look at all
> the changes.
i am new to kernel sources and kernel programming and
thank you for informing me on the diff(1).
thanks to you that the problem was solved (i don't
know if it is completely ok). i found that
- i had made mistake in computing checksum.
earlier checksum was computed over the whole
data but now i calculate checksum over the
header only.
- byte ordering.
tell me one thing isn't the byte order of the
ip_id in network byte order in the mbuf when passed
to the if_output() ??
i had to use the htons() to ip_id before computing
the checksum
- final thing does this makes any difference
(calling the htons() twice):
ip->ip_id=htons(ip->ip_id);
ip->ip_id=htons(ip->ip_id);
I will try put up patchfiles on web.
thanks very much,
kamal
__
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
