LinuxAnswers - the LQ Linux tutorial section.
Go Back > Forums > Linux Forums > Linux - Software > Linux - Kernel
User Name
Linux - Kernel This forum is for all discussion relating to the Linux kernel.


  Search this Thread
Old 04-22-2009, 12:10 AM   #1
Registered: May 2007
Location: New Zealand
Distribution: Ubuntu
Posts: 88

Rep: Reputation: 16
Question How to tell if a packet is reaching TCP?

Hi, I have written a network driver and it is sending and receiving packets, and I can use wget to download something from the internet, but when I try to run a webserver or telnetd and initiate the TCP session from another computer, it does not work.

I want to check if the packets sent from the other computer are being passed up the layers correctly. I know they are reaching the device driver because I printk them there. I know they are being passed up using "netif_rx".

Could someone please tell me what the other functions are which handle packets so I can add printk's through out the kernel to check they are being passed correctly?

"netif_rx" looks like it calls "skb_queue_tail" to queue up the packet for the upper layers. Where would I find the functions that next deal with the skb?

For completeness, I am running uClinux on a Nios II, but any ideas are appreciated!

Old 04-24-2009, 03:19 PM   #2
Registered: Feb 2002
Location: Grenoble
Distribution: Debian
Posts: 9,555

Rep: Reputation: 161Reputation: 161
I'd try first with ping. Both from the kernel in question and to the kernel in question. If ping works correctly, it's something at the higher layers, so it may be worth it to add printk to net/ipv4/ip_input.c ip_rcv function and ipv4/tcp_ipv4.c in tcp_v4_rcv. Of couse, if the packets reach both functions, it will be just the beginning. On the other hand, if ping doesn't work, it may be something below the routing level. Are you sure they are added to the queue by netif_rx?
Old 04-28-2009, 06:50 PM   #3
Registered: May 2007
Location: New Zealand
Distribution: Ubuntu
Posts: 88

Original Poster
Rep: Reputation: 16
Thanks Mara! I had been looking around that directory but didn't know what files had the reception functions in.

I can ping to and from the problem kernel.

I have just added the printks to those files. After some testing I will (hopefully) be back to ask what functions pass things further up the stack.

Old 04-30-2009, 04:45 PM   #4
Registered: May 2007
Location: New Zealand
Distribution: Ubuntu
Posts: 88

Original Poster
Rep: Reputation: 16
The testing procedure I am currently doing is:
- Both computers are connected directly
- My PC is and the Nios
- They can ping each other reliably.
- I start Boa (webserver) on the Nios
- From my PC, I can wget the home page and text files (~500bytes) from the Nios, the TCP sessions are successful
I have added printk's to ip_input.c and tcp_ipv4.c on the Nios. For the successful "HTTP GET" packets I can see that the skb gets passed up from "netif_rx" to "ip_rcv" and then to "tcp_v4_do_rcv" where "sk->sk_state == TCP_ESTABLISHED".

[caleb@localhost uClinux-dist]$ wget
--2009-05-01 09:07:28--
Connecting to connected.
HTTP request sent, awaiting response... 200 OK
Length: 388 [text/html]
Saving to: `index.html.51'

100%[======================================>] 388 --.-K/s in 0s

2009-05-01 09:07:28 (37.8 MB/s) - `index.html.51' saved [388/388]

- From my PC, I try to wget an image (~20kbytes) from the Nios. Now, the PC keeps resending "HTTP GET" requests but the Nios does not reply.
I now see these "HTTP GET" packets are being correctly passed up by "netif_rx", then "ip_rcv", then "tcp_v4_rcv" but are dropped in "tcp_v4_do_rcv"

	if (sk->sk_state == TCP_LISTEN) {
		struct sock *nsk = tcp_v4_hnd_req(sk, skb);
		if (!nsk)	{
			printk("tcp_v4_do_rcv: !nsk\n");	 <---------------- FAILS HERE
			goto discard;

		if (nsk != sk) {
			if (tcp_child_process(sk, nsk, skb)) {
				rsk = nsk;
				goto reset;
			return 0;

[caleb@localhost uClinux-dist]$ wget
--2009-05-01 09:08:42--
Connecting to connected.
HTTP request sent, awaiting response... *WAITS HERE FOREVER*
Do you know what the tcp_v4_hnd_req function is meant to do?
Old 04-30-2009, 07:34 PM   #5
Senior Member
Registered: Apr 2009
Posts: 1,310

Rep: Reputation: 118Reputation: 118
The tcp_v4_hnd_req does open request and sync cookie checking. On other hand, server reject your HTTP connection when server receive SYN. Check your HTTP server configuration.
Old 05-07-2009, 10:57 PM   #6
Registered: May 2007
Location: New Zealand
Distribution: Ubuntu
Posts: 88

Original Poster
Rep: Reputation: 16
Hi again.

I added the line
to my driver and edited my boa.conf file and now have the basic web server running. I start the server (boa) in uClinux by typing "boa &". When I go to cgi, html, text or css files in firefox they display correctly, but some images do not.

I have a set of images which I am testing with (just screenshots and logos from my desktop). There are two images (one .jpg one .png) which consistently work in Firefox. There are three images which consistently do not work in firefox.(two .pngs one .jpg)

I can use "wget" to download the images that do not work in firefox, but the images that do work in firefox do not work in wget!!

I have a screenshot test.png for example, it works in firefox but not in wget. On the uClinux machine I run "cp test.png test2.png". test2.png now downloads in wget, but does not display in firefox!

At first I thought this was related to Boa, but if I run httpd instead of boa to host the pages, it shows the same behaviour.

Any help will be much appreciated as I have hit another brick wall in my development and I can't figure it out!

My boa.conf file is:
# Boa v0.94 configuration file
# File format has changed little from 0.92
# version changes are noted in the comments
# The Boa configuration file is parsed with a lex/yacc or flex/bison
# generated parser. If it reports an error, the line number will be
# provided; it should be easy to spot. The syntax of each of these
# rules is very simple, and they can occur in any order. Where possible
# these directives mimic those of NCSA httpd 1.3; I saw no reason to
# introduce gratuitous differences.

# The "ServerRoot" is not in this configuration file. It can be compiled
# into the server (see defines.h) or specified on the command line with
# the -c option, for example:
# boa -c /usr

# Port: The port Boa runs on. The default port for http servers is 80.
# If it is less than 1024, the server must be started as root.

Port 80

# User: The name or UID the server should run as.
# Group: The group name or GID the server should run as.

User root
Group root

# ServerAdmin: The email address where server problems should be sent.
# Note: this is not currently used.

#ServerAdmin root@localhost

# ErrorLog: The location of the error log file. If this does not start
# with /, it is considered relative to the server root.
# Set to /dev/null if you don't want errors logged.

ErrorLog /var/log/boa/error_log

# AccessLog: The location of the access log file. If this does not
# start with /, it is considered relative to the server root.
# Comment out or set to /dev/null (less effective) to disable
# Access logging.

AccessLog /var/log/boa/access_log

# RefererLog: The location of the referer log file. If this does not
# start with /, it is considered relative to the server root.
# Comment out or set to /dev/null (less effective) to disable
# referer logging.

RefererLog /var/log/boa/referer_log

# AgentLog: The location of the agent log file. If this does not
# start with /, it is considered relative to the server root.
# Comment out or set to /dev/null (less effective) to disable
# User-Agent logging.

AgentLog /var/log/boa/agent_log

# VerboseCGILogs: this is just a logical switch.
# Comment out to disable.


# ServerName: the name of this server that should be sent back to
# clients if different than that returned by gethostname -- often
# this is

ServerName uClinux

# DocumentRoot: The root directory of the HTML documents.

DocumentRoot /home/httpd

# ChRoot: Boa root '/' directory. This is useful to improve security of
# your system. Don't forget that ALL DIRECTORIES used by boa except logs
# must be in this directory. If you need cgi scripts, you must copy shared
# libraries to this directory (see ldconfig(8) for more info)

#Chroot /var

# UserDir: The name of the directory which is appended onto a user's home
# directory if a ~user request is recieved.

UserDir public_html

# DirectoryIndex: Name of the file to use as a pre-written HTML
# directory index. Please MAKE AND USE THESE FILES. On the
# fly creation of directory indexes can be _slow_.

DirectoryIndex index.html

#DirectoryMaker /usr/boa_indexer

# LocalCodepage: Local codepage. This is send to client in 'Content-Type:'
# header by default.

#LocalCodepage iso-8859-1

# Codepage: Load codepage conversion table from file. This table will be used
# on-the-fly conversion.

#Codepage us-ascii /usr/lib/boa/iso-8859-2/us-ascii

# CodepageByURL: Specify URL prefix codepage. This command is used for manual
# codepage selection. For example,
# converts /document.html to us-ascii

#CodepageByURL /asc us-ascii

# CodepageByBrowser: Specify codepage by $USER_AGENT. This command is used for
# automatic codepage selection. You can use characters '*' and '?' in browser
# string. For example, "CodepageByBrowser Lynx/* us-ascii" will send for Lynx
# users all documents in us-ascii.

#CodepageByBrowser Lynx/* us-ascii

# KeepAliveMax: Number of KeepAlive requests to allow per connection
# Comment out, or set to 0 to disable keepalive processing

KeepAliveMax 100

# KeepAliveTimeout: seconds to wait before keepalive connection times out

KeepAliveTimeout 20

# MimeTypes: This is the file that is used to generate mime type pairs
# and Content-Type fields for boa.

MimeTypes /etc/mime.types

# DefaultType: MIME type used if the file extension is unknown, or there
# is no file extension.

DefaultType text/html

# AddType: adds types without editing mime.types
# Example: AddType type extension [extension ...]

# Uncomment the next line if you want .cgi files to execute from anywhere
#AddType application/x-httpd-cgi cgi

# Redirect, Alias, and ScriptAlias all have the same semantics -- they
# match the beginning of a request and take appropriate action. Use
# Redirect for other servers, Alias for the same server, and ScriptAlias
# to enable directories for script execution.

# Redirect allows you to tell clients about documents which used to exist in
# your server's namespace, but do not anymore. This allows you to tell the
# clients where to look for the relocated document.
# Example: Redirect /bar http://elsewhere/feh/bar

# Aliases: Aliases one path to another.
# Example: Alias /path1/bar /path2/foo

#Alias /doc /usr/doc

# ScriptAlias: Maps a virtual path to a directory for serving scripts
# Example: ScriptAlias /htbin/ /www/htbin/

#ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/

# VirtualHost: Maps a virtual host to a directory.
# Example: VirtualHost /html/htdocs/boa/

#VirtualHost /var/www/second_company/

# Auth: HTTP Basic authorization. Format is "Auth <Directory> <PasswdFile>".
# Password file should be readable _ONLY_ by root or trusted user(s). This file
# is opened before boa gives out privs.
# Example: Auth /secret /var/www/secret.passwd

#Auth /etc /etc/passwd
and my mime.types file is
# sample mime.types

text/html html htm
text/vnd.wap.wml wml
text/vnd.wap.wmlscript wmls
text/css css
text/plain asc txt
text/x-setext etx
text/richtext rtx
text/tab-separated-values tsv

image/gif gif
image/ief ief
image/jpeg jpe jpeg jpg
image/png png
image/tiff tiff tif
image/x-portable-bitmap pbm
image/x-portable-graymap pgm
image/x-portable-anymap pnm
image/x-portable-pixmap ppm
image/x-cmu-raster ras
image/x-rgb rgb
image/x-xbitmap xbm
image/x-xpixmap xpm
image/x-xwindowdump xwd

application/postscript ps eps
application/pgp pgp
application/x-bcpio bcpio
application/octet-stream bin
application/x-netcdf cdf
application/x-cpio cpio
application/x-csh csh
application/x-dvi dvi
application/andrew-inset ez
application/x-gtar gtar
application/x-gunzip gz
application/x-hdf hdf
application/x-latex latex
application/x-troff-man man
application/x-troff-me me
application/x-mif mif
application/x-troff-ms ms
application/x-netcdf nc
application/oda oda
application/pdf pdf
application/x-chess-pgn pgn
application/x-troff roff
application/rtf rtf
application/x-wais-source src
application/x-sv4cpio sv4cpio
application/x-sv4crc sv4crc
application/x-troff t tr
application/x-tar tar
application/x-tcl tcl
application/x-tex tex
application/x-texinfo texi texinfo
application/zip zip
application/xml xml
application/x-gtar gtar
application/x-gzip gz
application/x-httpd-php3 php3
application/x-rtsp-tunnelled amp 3gp
application/zip zip
application/sdp sdp
application/x-sh sh
application/x-shar shar
application/x-ustar ustar

audio/x-aiff aif aifc aiff
audio/ulaw au
audio/basic snd
audio/x-wav wav
audio/mpeg mpga mp2

video/x-msvideo avi
video/quicktime mov qt
video/x-sgi-movie movie
video/mpeg mp2 mpe mpeg mpg
Old 05-10-2009, 05:17 PM   #7
Registered: Feb 2002
Location: Grenoble
Distribution: Debian
Posts: 9,555

Rep: Reputation: 161Reputation: 161
Wget and firefox download files differently and the differences are quite subtle. I think you should make friends with Wireshark, if you haven't already. Run it, then download the on the files in question with wget and firefox. There are differences, for sure. The firefox trace should have some errors (http? or maybe tcp reset?) If you're unsure of what you see, post the essentials about the packets going. This will hopefully lead to an option in the server or in your driver.

BTW That checsumming part is worth checking. Are you sure this part is handled correctly? Please check three times.
Old 05-12-2009, 07:05 PM   #8
Registered: May 2007
Location: New Zealand
Distribution: Ubuntu
Posts: 88

Original Poster
Rep: Reputation: 16
Hi Mara

I am currently researching and testing the checksum options to confirm I am using the right one.

I have been observing the differences in the wget and firefox packets when trying to request the same file. When I try to request a file which works in wget and not firefox, the only differences (apart from timestamps/checksums) in the "get" packets sent are:

< GET /testing/1.png HTTP/1.0\r\n
> GET /testing/1.png HTTP/1.1\r\n

< Request Version: HTTP/1.0
< User-Agent: Wget/1.11.4 (Red Hat modified)\r\n
< Accept: */*\r\n
> Request Version: HTTP/1.1
> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/2009042708 Fedora/3.0.10-1.fc9 Firefox/3.0.10\r\n
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n
> Accept-Language: en-us,en;q=0.5\r\n
> Accept-Encoding: gzip,deflate\r\n
> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n

< Connection: Keep-Alive\r\n
> Keep-Alive: 300\r\n
> Connection: keep-alive\r\n
where the HTTP/1.0 session is wget and HTTP/1.1 session is firefox.

Both sessions receive the same "ACK" frame.

For wget, after sending an ACK frame, the server sends:
No. Time Source Destination Protocol Info
108 57.667070 TCP [TCP segment of a reassembled PDU]

No. Time Source Destination Protocol Info
109 57.667088 TCP 49594 > http [ACK] Seq=135 Ack=1025 Win=7936 Len=0 TSV=1612865 TSER=4294954844
repeated until;the entire data has been sent then
No. Time Source Destination Protocol Info
497 108.606065 HTTP HTTP/1.0 200 OK (PNG)

For the firefox session, there is no further reply after the ACK frame, then almost 20seconds later the client must time out and the following exchange occurs:
No. Time Source Destination Protocol Info
69 46.721333 TCP 49593 > http [FIN, ACK] Seq=398 Ack=1 Win=5888 Len=0 TSV=1601919 TSER=4294951717

No. Time Source Destination Protocol Info
70 46.861844 TCP http > 49593 [FIN, ACK] Seq=1 Ack=399 Win=6864 Len=0 TSV=4294953970 TSER=1601919

No. Time Source Destination Protocol Info
71 46.861878 TCP 49593 > http [ACK] Seq=399 Ack=2 Win=5888 Len=0 TSV=1602060 TSER=4294953970

Could there be a problem with HTTP/1.1? that seems unlikely as it works for some images...? Does this give you any ideas as to where things are going wrong?


Last edited by AustinMarton; 05-12-2009 at 07:07 PM.
Old 05-12-2009, 07:22 PM   #9
Registered: May 2007
Location: New Zealand
Distribution: Ubuntu
Posts: 88

Original Poster
Rep: Reputation: 16
I have now compared the difference between a file which firefox can download (/include/logo.png) and a file it can't (/testing/1.png).

The ONLY differences that are not checksums, timestamps or sizes are:
< GET /include/logo.png HTTP/1.1\r\n
> GET /testing/1.png HTTP/1.1\r\n

< Request URI: /include/logo.png
> Request URI: /testing/1.png
I think this means the problem must be in the boa web server software? Permissions?


fails, ping, tcp, uclinux, works

Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
TCP Packet Size ajkannan83 General 3 11-03-2005 06:46 AM
problem in TCP packet live_dont_exist Programming 3 05-16-2005 06:00 AM
TCP Packet Collisions artematalento Linux - Networking 5 11-11-2004 08:48 PM
tcp packet size dellcom1800 Linux - Networking 2 07-28-2004 07:49 AM
Linux tcp/ip packet optimizer wildtiger23 Linux - Networking 1 06-09-2004 05:00 PM

All times are GMT -5. The time now is 02:00 AM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration