[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: skb_put() causes the system to loop
Hello Samarth...
> I was struggling for around 2 weeks without any success. You seem to
> have given me the hint. Thanks a lot for replying to the mail
You're welcome. Actually, we share common interest (Linux network
stack), but I am still a beginner too. So, this is somekind of "quiz"
for me :)
BTW, you shouldn't do top posting. The reason is simple IMHO. If you are
replying by writing below the related paragraph/words, the e-mail
receiver will easily follow the flow of your logic without forced to
look up and down between yours and the replied sentences.
> 1) I want to send some additional data everytime an ack is sent
> 2) When the sender recieves the ack packet it would extract this
> additional data and use it for some computation
Understood. So, by looking at your proposed step #2, logically, you need
to modify something at the receiver side, right? If not, the receiver
will think the real ack + your additional data = invalid ack, thus
asking the ack sender to resend the packet or think that it is a valid
data and thus sending another ACK. CMIIW
And maybe, do we need to consider Maximum Transfer Unit or Fragmentation
issue here? I mean, maybe your ack+modified data is splitted into two
fragment and somehow the receiver sees it in reverse order or
incorrectly re-assemble the packet? Personally, I am not so sure, i am
just throwing ideas to watch for.
Another thing, do you append your data such as "ack+modified data" (ack
is on lower address, but sorry, so far I never studied the way NIC
stores data to its own buffer) or "modified data+ack" (ack is on higher
address)?
> I plan to put the additional data that I intent to send in the extra
> space allocated in the tcp header.(alloc_skb(2*MAX_TCP_HEADER)) .
> I have attached the tcp_output.c file.To get the initial version
> working I put only a string "Test\n" in the data section.Later on i
> will put the acutal data that i intend to send
Next time, please just attach your patch (not the entire C file), or if
you really need to send the whole lines, you can compress it (gz, zip,
bz2, anything you prefer).
> 1) A sends data to B
> 2) B sends modified acknowledgement header to A
> 3) A recieves the acknowldegement from B and also recieves the data
> that was added to the end of the header
> 4) A sends a modified_acknowledgement packet to the acknowledge the
> packet it recieves from B...
IMHO, these are the things that really happens:
#1 - #2 correct
in #3, ack+data is received by A. A tries to parse the received ACK, but
failed due to the additional data. Chances are:
a) Received data (ack+your data) is simply typecasted by A. A then tried
to find the string/number to identify if it is really an ACK or not.
But it failed and think that B is actually sending data to A and A
quickly sends ACK to acknowledge this data.
Got my idea here?
b) A correctly understood the the packet is indeed an ACK packet. But
then it thinks "hm, what does this additional mean? A flag? Well, maybe
host B did something wrong here"
Both scenario (maybe there are others) create a never ending ping pong
between A and B (as you already guessed). But somehow I feel, case (a)
is the one you faced.
Try to implement my ideas above about modifying the receiver side.
And let's see these codes:
---------------------------------------------------------------------------------
skb_put(buff,MAX_TCP_HEADER);
unsigned char *temp = (unsigned char *)(buff+MAX_TCP_BUFFER);
strncpy(temp,"Test\n",6);
------------------------------------------------------------------------------------
a) 6? are you sure? Not 5? And, you sure you don't need extra "\0" so it
will be null terminated?
b) +MAX_TCP_BUFFER? Not MAX_TCP_HEADER?
NB: Boiled down by having to look at 2 computer at once or need to peek
directly on how network stack code works? Several times I suggested
folks who did network stack hacking to use User Mode Linux, maybe you
can adopt it too.
regards
Mulyadi
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/