Linux - KernelThis forum is for all discussion relating to the Linux kernel.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Distribution: Fedora at home, Ubuntu 10.04 at work
Posts: 88
Rep:
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!
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?
Distribution: Fedora at home, Ubuntu 10.04 at work
Posts: 88
Original Poster
Rep:
The testing procedure I am currently doing is:
- Both computers are connected directly
- My PC is 10.42.43.1 and the Nios 10.42.43.10
- 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".
Quote:
[caleb@localhost uClinux-dist]$ wget http://10.42.43.10
--2009-05-01 09:07:28-- http://10.42.43.10/
Connecting to 10.42.43.10:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 388 [text/html]
Saving to: `index.html.51'
100%[======================================>] 388 --.-K/s in 0s
- 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"
Code:
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;
}
}
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.
Distribution: Fedora at home, Ubuntu 10.04 at work
Posts: 88
Original Poster
Rep:
Hi again.
I added the line
Code:
skb->ip_summed = CHECKSUM_UNNECESSARY
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:
Quote:
# 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.
#VerboseCGILogs
# ServerName: the name of this server that should be sent back to
# clients if different than that returned by gethostname -- often
# this is www.foo.bar.
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.
# CodepageByURL: Specify URL prefix codepage. This command is used for manual
# codepage selection. For example, http://www.cz.boa.org/asc/document.html
# 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
#plain
#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 cz.boa.org /html/htdocs/boa/
# 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
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.
Distribution: Fedora at home, Ubuntu 10.04 at work
Posts: 88
Original Poster
Rep:
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:
Quote:
72c72
< GET /testing/1.png HTTP/1.0\r\n
---
> GET /testing/1.png HTTP/1.1\r\n
No. Time Source Destination Protocol Info
497 108.606065 192.168.96.168 192.168.96.115 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:
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?
Thanks,
Austin.
Last edited by AustinMarton; 05-12-2009 at 08:07 PM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.