agnx80211driver-devel Mailing List for Airgo MIMO Wireless Card Linux Driver
Status: Alpha
Brought to you by:
dreamfly281
Menu
▾
▴
agnx80211driver-devel — Airgo MIMO Wireless Card AGNX Linux Driver
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(9) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
|
From: <Tia...@nu...> - 2008-11-06 10:07:12
|
Hi YanBo,I would like to know if this driver support 802.11n, especially packet aggregation and Block ACK or not? Thx a lot.BRTianji |
|
From: YanBo <dre...@gm...> - 2008-10-18 03:41:54
|
---------- Forwarded message ---------- From: YanBo <dre...@gm...> Date: Sat, Oct 18, 2008 at 11:40 AM Subject: Re: AGNX Airgo Driver To: mdtex <cc...@gm...> Cc: Jeff willam <ang...@gm...> On Sat, Oct 18, 2008 at 3:01 AM, mdtex <cc...@gm...> wrote: > Hello: > I have a linksys WPC54GX with a Airgo chipset on it. To get it working I > made some modifications to your code, and I thought you would like a copy. > Most of the changes are in pci.c and agnx.h, the other mods are minor. The > attached tar file contains the files. > > Thank you > Clyde McPherson > > Good, the code was too long hasn't update cause my lazy :) I'll update your change to the new version. Could you send me a sign off of yourself. BTW, how about the process and result when you test it in WPC54GX? Thanks! BR Yanbo resend with mail list. |
|
From: YanBo <dre...@gm...> - 2008-04-26 02:00:10
|
On Fri, Apr 25, 2008 at 12:23 AM, Wessam Baghdadi <wba...@gm...> wrote: > 2008/4/21 YanBo <dre...@gm...>: > > > > On Fri, Apr 18, 2008 at 6:30 PM, Wessam Baghdadi <wba...@gm...> wrote: > > > Hi, > > > > > > I just came across your driver - yet to test it (using ndiswrapper + > > > Linksys WMP54GX), but thanks in advance. > > > > > > A couple of questions for you: > > > > > > What is the current status of the driver? Is it working for both > > > AGN100 and AGN300? > > > > > > > Just for AGN100 at this monment, but not very stable, specify speak, > > it will lost the associate after a while and the highest TX speed > > just reached to 8Mbit/S. > > > > > > > Looking at the git tree here > > > http://git.sipsolutions.net/?p=agnx.git;a=summary I can't see any new > > > commits since January. > > > > Yes, It is my fault, I am very busy for another company's project > > recently. hence have not too much time to maintain and update the > > code, but I want to spend more time on it when I have time in later. > > > > > > > > > > Has this driver been incorporated into the current kernel wireless stack? > > > > > > > Not yet. > > > > > > > Is all the documentation here http://airgo.wdwconsulting.net/mymoin > > > complete? What is missing? > > > > > > > Yes, all reverse engineer chipset info are local in this Website. it > > was maintained by Jeff, but he has quit this project for something he > > has to do. as you know, this driver is totally based on reverse > > engineer, and lot of hardware detail hasn't been figure out yet, so > > this is the biggest > > balk for this project. If any volunteer like to burden this task, it > > will be greatly welcome. > > > > > > > I'm interested in contacted the Linux Driver Project > > > http://www.linuxdriverproject.org/twiki/bin/view to see if they will > > > continue the development/maintenance of the driver and incorporate it > > > in the wireless stack. > > > > > > > It is also greatly welcome. Thanks. > > > > BR > > Li Yanbo > > > > I understand that Airgo released some GPL code a while back > (http://web.archive.org/web/20051219012536/http://gpl.airgonetworks.com/) > and Belkin released the GPL source & toolchain to their F5D9630 Not sure F5D9630 contain the Airgo chipset, FWIK F5d8010 contain the agn100 chipset > (Wireless G+ MIMO Modem Router) recently - I have no idea if this code > includes source related to the chipset or if Jeff looked at this > source when reverse eng the specs. > The Linksys published the source code for WRT54GX in its website, and it contains the binary driver for Agn100. I guess Jeff also has some binary code of Agn300, but don't know specify. > Airgo is now part of Qualcomm, but surprisingly enough there is a > claim that one of the airgo engineers had developed linux drivers that > were held back. > (http://www.linuxelectrons.com/news/mobile/airgo-and-asus-team-launch-faster-wired-laptop). > He still works at Qualcomm and has a linkedin profile here > (http://www.linkedin.com/in/cfliu) > > Is it possible that one of the maintainers could get in touch with him to see: > > * if these mythical drivers were indeed developed, the status of the > drivers and the possibility of Qualcomm releasing the source? > I never find any clue about this driver.BTW I had contacted with some people of Airgo company, but all has no response. > * the possibility of releasing the complete specifications of the chipset? > > If no one here is the right person to get in touch with David, perhaps > someone can point me in the right direction? I'll retry to get in touch with him. Thank your support for this project! BR Li Yanbo |
|
From: Wessam B. <wba...@gm...> - 2008-04-24 16:23:15
|
2008/4/21 YanBo <dre...@gm...>: > On Fri, Apr 18, 2008 at 6:30 PM, Wessam Baghdadi <wba...@gm...> wrote: > > Hi, > > > > I just came across your driver - yet to test it (using ndiswrapper + > > Linksys WMP54GX), but thanks in advance. > > > > A couple of questions for you: > > > > What is the current status of the driver? Is it working for both > > AGN100 and AGN300? > > > > Just for AGN100 at this monment, but not very stable, specify speak, > it will lost the associate after a while and the highest TX speed > just reached to 8Mbit/S. > > > > Looking at the git tree here > > http://git.sipsolutions.net/?p=agnx.git;a=summary I can't see any new > > commits since January. > > Yes, It is my fault, I am very busy for another company's project > recently. hence have not too much time to maintain and update the > code, but I want to spend more time on it when I have time in later. > > > > > > Has this driver been incorporated into the current kernel wireless stack? > > > > Not yet. > > > > Is all the documentation here http://airgo.wdwconsulting.net/mymoin > > complete? What is missing? > > > > Yes, all reverse engineer chipset info are local in this Website. it > was maintained by Jeff, but he has quit this project for something he > has to do. as you know, this driver is totally based on reverse > engineer, and lot of hardware detail hasn't been figure out yet, so > this is the biggest > balk for this project. If any volunteer like to burden this task, it > will be greatly welcome. > > > > I'm interested in contacted the Linux Driver Project > > http://www.linuxdriverproject.org/twiki/bin/view to see if they will > > continue the development/maintenance of the driver and incorporate it > > in the wireless stack. > > > > It is also greatly welcome. Thanks. > > BR > Li Yanbo > I understand that Airgo released some GPL code a while back (http://web.archive.org/web/20051219012536/http://gpl.airgonetworks.com/) and Belkin released the GPL source & toolchain to their F5D9630 (Wireless G+ MIMO Modem Router) recently - I have no idea if this code includes source related to the chipset or if Jeff looked at this source when reverse eng the specs. Airgo is now part of Qualcomm, but surprisingly enough there is a claim that one of the airgo engineers had developed linux drivers that were held back. (http://www.linuxelectrons.com/news/mobile/airgo-and-asus-team-launch-faster-wired-laptop). He still works at Qualcomm and has a linkedin profile here (http://www.linkedin.com/in/cfliu) Is it possible that one of the maintainers could get in touch with him to see: * if these mythical drivers were indeed developed, the status of the drivers and the possibility of Qualcomm releasing the source? * the possibility of releasing the complete specifications of the chipset? If no one here is the right person to get in touch with David, perhaps someone can point me in the right direction? thanks, wessam |
|
From: YanBo <dre...@gm...> - 2008-04-21 02:17:50
|
On Fri, Apr 18, 2008 at 6:30 PM, Wessam Baghdadi <wba...@gm...> wrote: > Hi, > > I just came across your driver - yet to test it (using ndiswrapper + > Linksys WMP54GX), but thanks in advance. > > A couple of questions for you: > > What is the current status of the driver? Is it working for both > AGN100 and AGN300? > Just for AGN100 at this monment, but not very stable, specify speak, it will lost the associate after a while and the highest TX speed just reached to 8Mbit/S. > Looking at the git tree here > http://git.sipsolutions.net/?p=agnx.git;a=summary I can't see any new > commits since January. Yes, It is my fault, I am very busy for another company's project recently. hence have not too much time to maintain and update the code, but I want to spend more time on it when I have time in later. > > Has this driver been incorporated into the current kernel wireless stack? > Not yet. > Is all the documentation here http://airgo.wdwconsulting.net/mymoin > complete? What is missing? > Yes, all reverse engineer chipset info are local in this Website. it was maintained by Jeff, but he has quit this project for something he has to do. as you know, this driver is totally based on reverse engineer, and lot of hardware detail hasn't been figure out yet, so this is the biggest balk for this project. If any volunteer like to burden this task, it will be greatly welcome. > I'm interested in contacted the Linux Driver Project > http://www.linuxdriverproject.org/twiki/bin/view to see if they will > continue the development/maintenance of the driver and incorporate it > in the wireless stack. > It is also greatly welcome. Thanks. BR Li Yanbo |
|
From: YanBo <dre...@gm...> - 2007-12-23 14:45:05
|
> On Dec 23, 2007 9:31 PM, YanBo < dre...@gm...> wrote: > > > > On Dec 23, 2007 8:51 PM, far seer <se...@gm...> wrote: > > > YanBo, > > > I want to descripte the driver work flow: after user send http request > via > > > socket, then agnx_tx deal with the requeset, the result is raising a > > > interrupt. In interrupt handl, handle_txd_irq is responsed for > transfering > > > data. Is it right? > > > > yes. totally right. > > > > > > > I find agnx_tx at line 3018 in agnx.dmesg which is http request, and > > > > no it get the handle interrupt in the line 3653 > > > > > > > > > > > following report have no interrupt handle for handle_txd_irq. > > > Because there is no interrupt reason with AGNX_STAT_TXD. > > > > > > BR > > > > > > > On Dec 23, 2007 10:26 PM, far seer <se...@gm...> wrote: > Is this line? > [ 1821.101561] agnx: Interrupt reason is 0x801 > but AGNX_STAT_TXD can't not been masked by it, since No matter txm or txd was triggered, all what will see is the interrupt reason register is 0x801. > #define AGNX_STAT_TXD 0x10 This is define by myself to distinguish txd and txm, it will no be know by hardware. There is a comment above this code: /* Below two interrupt flags will be set by our but not CPU */ lyb |
|
From: far s. <se...@gm...> - 2007-12-23 12:51:08
|
YanBo, I want to descripte the driver work flow: after user send http request via socket, then agnx_tx deal with the requeset, the result is raising a interrupt. In interrupt handl, handle_txd_irq is responsed for transfering data. Is it right? I find agnx_tx at line 3018 in agnx.dmesg which is http request, and following report have no interrupt handle for handle_txd_irq. Because there is no interrupt reason with AGNX_STAT_TXD. BR |
|
From: YanBo <dre...@gm...> - 2007-12-23 06:46:32
|
> > On Dec 23, 2007 2:19 PM, YanBo <dre...@gm... > wrote: > > > > > > > > > > > > On Dec 23, 2007 2:03 PM, YanBo < dre...@gm...> wrote: > > > > > > > > > > > > > > > > On Dec 23, 2007 12:45 PM, far seer <se...@gm... > wrote: > > > > > YanBo, > > > > > Below is tcpdump report, though google does not send fin package > after > > > three > > > > > handshake. > > > > > > > > > > 12:41:19.157286 IP 192.168.1.122.50637 > jp-in-f147.google.com.http: > S > > > > > 2707899440:2707899440(0) win 5840 <mss 1460,sackOK,timestamp 500377 > > > > > 0,nop,wscale 4> > > > > > 12:41: 19.267147 IP jp-in-f147.google.com.http > > 192.168.1.122.50637: S > > > > > 3578420469:3578420469(0) ack 2707899441 win 5672 <mss > > > 1430,sackOK,timestamp > > > > > 3714633827 500377,nop,wscale 6> > > > > > 12:41:19.267183 IP 192.168.1.122.50637 > jp-in-f147.google.com.http: > . > > > ack 1 > > > > > win 365 <nop,nop,timestamp 500487 3714633827> > > > > > 12:41:20.267347 IP 192.168.1.122.50637 > jp-in-f147.google.com.http > : P > > > > > 1:32(31) ack 1 win 365 <nop,nop,timestamp 501487 3714633827> > > > > > 12:41:20.377030 IP jp-in-f147.google.com.http > 192.168.1.122.50637: > . > > > ack > > > > > 32 win 89 <nop,nop,timestamp 3714634938 501487> > > > > > 12:41:20.419030 IP jp-in-f147.google.com.http > 192.168.1.122.50637 > : . > > > > > 1:1419(1418) ack 32 win 89 <nop,nop,timestamp 3714634974 501487> > > > > > 12:41:20.419041 IP 192.168.1.122.50637 > jp-in-f147.google.com.http: > . > > > ack > > > > > 1419 win 546 <nop,nop,timestamp 501639 3714634974> > > > > > 12:41:20.424256 IP jp-in-f147.google.com.http > 192.168.1.122.50637: > . > > > > > 1419:2837(1418) ack 32 win 89 <nop,nop,timestamp 3714634974 501487> > > > > > 12:41:20.424291 IP 192.168.1.122.50637 > jp-in-f147.google.com.http > : . > > > ack > > > > > 2837 win 727 <nop,nop,timestamp 501644 3714634974> > > > > > 12:41:20.428219 IP jp-in-f147.google.com.http > 192.168.1.122.50637: > P > > > > > 2837:4255(1418) ack 32 win 89 <nop,nop,timestamp 3714634974 501487> > > > > > 12:41:20.428249 IP 192.168.1.122.50637 > jp-in-f147.google.com.http: > . > > > ack > > > > > 4255 win 908 <nop,nop,timestamp 501648 3714634974> > > > > > 12:41:20.532164 IP jp-in-f147.google.com.http > 192.168.1.122.50637 > : . > > > > > 4255:5673(1418) ack 32 win 89 <nop,nop,timestamp 3714635087 501639> > > > > > 12:41:20.532218 IP jp-in-f147.google.com.http > 192.168.1.122.50637: > FP > > > > > 5673:5675(2) ack 32 win 89 <nop,nop,timestamp 3714635087 501639> > > > > > 12:41:20.532279 IP 192.168.1.122.50637 > jp-in-f147.google.com.http > : . > > > ack > > > > > 5673 win 1089 <nop,nop,timestamp 501752 3714635087> > > > > > 12:41:20.532380 IP 192.168.1.122.50637 > jp-in-f147.google.com.http > : F > > > > > 32:32(0) ack 5676 win 1089 <nop,nop,timestamp 501752 3714635087> > > > > > 12:41: 20.643053 IP jp-in-f147.google.com.http > > 192.168.1.122.50637: . > > > ack > > > > > 33 win 89 <nop,nop,timestamp 3714635203 501752> > > > > > > > > > > > > > > Hi far. > > > > For the agnx card, google send fin packet because after finished three > > > > handshake, it wait for a while but still can't receive the http > > > > request from the client, so it think this tcp session is timeout, > > > > hence it sent the fin packet to terminal this tcp session, but in > > > > above situation google get the correctly http request after three > > > > handshake, so it will not send fin packet. > > > > > > > > lyb > > > > > > > > > > > > > > On Dec 23, 2007 2:09 PM, far seer < se...@gm...> wrote: > > > The case is delaying 1s to submit http request after three handshake. If > so, > > > google server should timeout too. The http_get code is like: > > > // connect to google server > > > // sleep(1) > > > > Please try sleep(10) or sleep(20). > > > > > > > // send the http request to google server (this is a get command, just > > > request default web) > > > > > > > > lyb > > > > On Dec 23, 2007 2:32 PM, far seer <se...@gm...> wrote: > Sleep 20s will timeout while sleep 10s will not. So, the threshold is at a > point from 10s to 20s. Yes, thanks for your effort to do these tests, and from them, I think, we can say this problem is caused by the card can't sent the http request packets to google, but not google's reason. lyb |
|
From: far s. <se...@gm...> - 2007-12-23 06:32:30
|
Sleep 20s will timeout while sleep 10s will not. So, the threshold is at a point from 10s to 20s. On Dec 23, 2007 2:19 PM, YanBo <dre...@gm...> wrote: > > > > On Dec 23, 2007 2:03 PM, YanBo <dre...@gm...> wrote: > > > > > > > > > > > > On Dec 23, 2007 12:45 PM, far seer <se...@gm...> wrote: > > > > YanBo, > > > > Below is tcpdump report, though google does not send fin package > after > > three > > > > handshake. > > > > > > > > 12:41:19.157286 IP 192.168.1.122.50637 > jp-in-f147.google.com.http: > S > > > > 2707899440:2707899440(0) win 5840 <mss 1460,sackOK,timestamp 500377 > > > > 0,nop,wscale 4> > > > > 12:41: 19.267147 IP jp-in-f147.google.com.http > 192.168.1.122.50637: > S > > > > 3578420469:3578420469(0) ack 2707899441 win 5672 <mss > > 1430,sackOK,timestamp > > > > 3714633827 500377,nop,wscale 6> > > > > 12:41:19.267183 IP 192.168.1.122.50637 > jp-in-f147.google.com.http: > . > > ack 1 > > > > win 365 <nop,nop,timestamp 500487 3714633827> > > > > 12:41:20.267347 IP 192.168.1.122.50637 > jp-in-f147.google.com.http: > P > > > > 1:32(31) ack 1 win 365 <nop,nop,timestamp 501487 3714633827> > > > > 12:41:20.377030 IP jp-in-f147.google.com.http > 192.168.1.122.50637: > . > > ack > > > > 32 win 89 <nop,nop,timestamp 3714634938 501487> > > > > 12:41:20.419030 IP jp-in-f147.google.com.http > 192.168.1.122.50637: . > > > > 1:1419(1418) ack 32 win 89 <nop,nop,timestamp 3714634974 501487> > > > > 12:41:20.419041 IP 192.168.1.122.50637 > jp-in-f147.google.com.http: > . > > ack > > > > 1419 win 546 <nop,nop,timestamp 501639 3714634974> > > > > 12:41:20.424256 IP jp-in-f147.google.com.http > 192.168.1.122.50637: > . > > > > 1419:2837(1418) ack 32 win 89 <nop,nop,timestamp 3714634974 501487> > > > > 12:41:20.424291 IP 192.168.1.122.50637 > jp-in-f147.google.com.http: . > > ack > > > > 2837 win 727 <nop,nop,timestamp 501644 3714634974> > > > > 12:41:20.428219 IP jp-in-f147.google.com.http > 192.168.1.122.50637: > P > > > > 2837:4255(1418) ack 32 win 89 <nop,nop,timestamp 3714634974 501487> > > > > 12:41:20.428249 IP 192.168.1.122.50637 > jp-in-f147.google.com.http: > . > > ack > > > > 4255 win 908 <nop,nop,timestamp 501648 3714634974> > > > > 12:41:20.532164 IP jp-in-f147.google.com.http > 192.168.1.122.50637: . > > > > 4255:5673(1418) ack 32 win 89 <nop,nop,timestamp 3714635087 501639> > > > > 12:41:20.532218 IP jp-in-f147.google.com.http > 192.168.1.122.50637: > FP > > > > 5673:5675(2) ack 32 win 89 <nop,nop,timestamp 3714635087 501639> > > > > 12:41:20.532279 IP 192.168.1.122.50637 > jp-in-f147.google.com.http: . > > ack > > > > 5673 win 1089 <nop,nop,timestamp 501752 3714635087> > > > > 12:41:20.532380 IP 192.168.1.122.50637 > jp-in-f147.google.com.http: F > > > > 32:32(0) ack 5676 win 1089 <nop,nop,timestamp 501752 3714635087> > > > > 12:41: 20.643053 IP jp-in-f147.google.com.http > 192.168.1.122.50637: > . > > ack > > > > 33 win 89 <nop,nop,timestamp 3714635203 501752> > > > > > > > > > > > Hi far. > > > For the agnx card, google send fin packet because after finished three > > > handshake, it wait for a while but still can't receive the http > > > request from the client, so it think this tcp session is timeout, > > > hence it sent the fin packet to terminal this tcp session, but in > > > above situation google get the correctly http request after three > > > handshake, so it will not send fin packet. > > > > > > lyb > > > > > > > > On Dec 23, 2007 2:09 PM, far seer <se...@gm...> wrote: > > The case is delaying 1s to submit http request after three handshake. If > so, > > google server should timeout too. The http_get code is like: > > // connect to google server > > // sleep(1) > > Please try sleep(10) or sleep(20). > > > // send the http request to google server (this is a get command, just > > request default web) > > > > > lyb > |
|
From: YanBo <dre...@gm...> - 2007-12-23 06:19:53
|
> > On Dec 23, 2007 2:03 PM, YanBo <dre...@gm...> wrote: > > > > > > > > On Dec 23, 2007 12:45 PM, far seer <se...@gm...> wrote: > > > YanBo, > > > Below is tcpdump report, though google does not send fin package after > three > > > handshake. > > > > > > 12:41:19.157286 IP 192.168.1.122.50637 > jp-in-f147.google.com.http: S > > > 2707899440:2707899440(0) win 5840 <mss 1460,sackOK,timestamp 500377 > > > 0,nop,wscale 4> > > > 12:41: 19.267147 IP jp-in-f147.google.com.http > 192.168.1.122.50637: S > > > 3578420469:3578420469(0) ack 2707899441 win 5672 <mss > 1430,sackOK,timestamp > > > 3714633827 500377,nop,wscale 6> > > > 12:41:19.267183 IP 192.168.1.122.50637 > jp-in-f147.google.com.http: . > ack 1 > > > win 365 <nop,nop,timestamp 500487 3714633827> > > > 12:41:20.267347 IP 192.168.1.122.50637 > jp-in-f147.google.com.http: P > > > 1:32(31) ack 1 win 365 <nop,nop,timestamp 501487 3714633827> > > > 12:41:20.377030 IP jp-in-f147.google.com.http > 192.168.1.122.50637: . > ack > > > 32 win 89 <nop,nop,timestamp 3714634938 501487> > > > 12:41:20.419030 IP jp-in-f147.google.com.http > 192.168.1.122.50637 : . > > > 1:1419(1418) ack 32 win 89 <nop,nop,timestamp 3714634974 501487> > > > 12:41:20.419041 IP 192.168.1.122.50637 > jp-in-f147.google.com.http: . > ack > > > 1419 win 546 <nop,nop,timestamp 501639 3714634974> > > > 12:41:20.424256 IP jp-in-f147.google.com.http > 192.168.1.122.50637: . > > > 1419:2837(1418) ack 32 win 89 <nop,nop,timestamp 3714634974 501487> > > > 12:41:20.424291 IP 192.168.1.122.50637 > jp-in-f147.google.com.http : . > ack > > > 2837 win 727 <nop,nop,timestamp 501644 3714634974> > > > 12:41:20.428219 IP jp-in-f147.google.com.http > 192.168.1.122.50637: P > > > 2837:4255(1418) ack 32 win 89 <nop,nop,timestamp 3714634974 501487> > > > 12:41:20.428249 IP 192.168.1.122.50637 > jp-in-f147.google.com.http: . > ack > > > 4255 win 908 <nop,nop,timestamp 501648 3714634974> > > > 12:41:20.532164 IP jp-in-f147.google.com.http > 192.168.1.122.50637 : . > > > 4255:5673(1418) ack 32 win 89 <nop,nop,timestamp 3714635087 501639> > > > 12:41:20.532218 IP jp-in-f147.google.com.http > 192.168.1.122.50637: FP > > > 5673:5675(2) ack 32 win 89 <nop,nop,timestamp 3714635087 501639> > > > 12:41:20.532279 IP 192.168.1.122.50637 > jp-in-f147.google.com.http : . > ack > > > 5673 win 1089 <nop,nop,timestamp 501752 3714635087> > > > 12:41:20.532380 IP 192.168.1.122.50637 > jp-in-f147.google.com.http : F > > > 32:32(0) ack 5676 win 1089 <nop,nop,timestamp 501752 3714635087> > > > 12:41: 20.643053 IP jp-in-f147.google.com.http > 192.168.1.122.50637: . > ack > > > 33 win 89 <nop,nop,timestamp 3714635203 501752> > > > > > > > > Hi far. > > For the agnx card, google send fin packet because after finished three > > handshake, it wait for a while but still can't receive the http > > request from the client, so it think this tcp session is timeout, > > hence it sent the fin packet to terminal this tcp session, but in > > above situation google get the correctly http request after three > > handshake, so it will not send fin packet. > > > > lyb > > > > On Dec 23, 2007 2:09 PM, far seer <se...@gm...> wrote: > The case is delaying 1s to submit http request after three handshake. If so, > google server should timeout too. The http_get code is like: > // connect to google server > // sleep(1) Please try sleep(10) or sleep(20). > // send the http request to google server (this is a get command, just > request default web) > > lyb |
|
From: far s. <se...@gm...> - 2007-12-23 06:09:28
|
The case is delaying 1s to submit http request after three handshake. If so, google server should timeout too. The http_get code is like: // connect to google server // sleep(1) // send the http request to google server (this is a get command, just request default web) On Dec 23, 2007 2:03 PM, YanBo <dre...@gm...> wrote: > On Dec 23, 2007 12:45 PM, far seer <se...@gm...> wrote: > > YanBo, > > Below is tcpdump report, though google does not send fin package after > three > > handshake. > > > > 12:41:19.157286 IP 192.168.1.122.50637 > jp-in-f147.google.com.http: S > > 2707899440:2707899440(0) win 5840 <mss 1460,sackOK,timestamp 500377 > > 0,nop,wscale 4> > > 12:41:19.267147 IP jp-in-f147.google.com.http > 192.168.1.122.50637: S > > 3578420469:3578420469(0) ack 2707899441 win 5672 <mss > 1430,sackOK,timestamp > > 3714633827 500377,nop,wscale 6> > > 12:41:19.267183 IP 192.168.1.122.50637 > jp-in-f147.google.com.http: . > ack 1 > > win 365 <nop,nop,timestamp 500487 3714633827> > > 12:41:20.267347 IP 192.168.1.122.50637 > jp-in-f147.google.com.http: P > > 1:32(31) ack 1 win 365 <nop,nop,timestamp 501487 3714633827> > > 12:41:20.377030 IP jp-in-f147.google.com.http > 192.168.1.122.50637: . > ack > > 32 win 89 <nop,nop,timestamp 3714634938 501487> > > 12:41:20.419030 IP jp-in-f147.google.com.http > 192.168.1.122.50637: . > > 1:1419(1418) ack 32 win 89 <nop,nop,timestamp 3714634974 501487> > > 12:41:20.419041 IP 192.168.1.122.50637 > jp-in-f147.google.com.http: . > ack > > 1419 win 546 <nop,nop,timestamp 501639 3714634974> > > 12:41:20.424256 IP jp-in-f147.google.com.http > 192.168.1.122.50637: . > > 1419:2837(1418) ack 32 win 89 <nop,nop,timestamp 3714634974 501487> > > 12:41:20.424291 IP 192.168.1.122.50637 > jp-in-f147.google.com.http: . > ack > > 2837 win 727 <nop,nop,timestamp 501644 3714634974> > > 12:41:20.428219 IP jp-in-f147.google.com.http > 192.168.1.122.50637: P > > 2837:4255(1418) ack 32 win 89 <nop,nop,timestamp 3714634974 501487> > > 12:41:20.428249 IP 192.168.1.122.50637 > jp-in-f147.google.com.http: . > ack > > 4255 win 908 <nop,nop,timestamp 501648 3714634974> > > 12:41:20.532164 IP jp-in-f147.google.com.http > 192.168.1.122.50637: . > > 4255:5673(1418) ack 32 win 89 <nop,nop,timestamp 3714635087 501639> > > 12:41:20.532218 IP jp-in-f147.google.com.http > 192.168.1.122.50637: FP > > 5673:5675(2) ack 32 win 89 <nop,nop,timestamp 3714635087 501639> > > 12:41:20.532279 IP 192.168.1.122.50637 > jp-in-f147.google.com.http : . > ack > > 5673 win 1089 <nop,nop,timestamp 501752 3714635087> > > 12:41:20.532380 IP 192.168.1.122.50637 > jp-in-f147.google.com.http: F > > 32:32(0) ack 5676 win 1089 <nop,nop,timestamp 501752 3714635087> > > 12:41: 20.643053 IP jp-in-f147.google.com.http > 192.168.1.122.50637: . > ack > > 33 win 89 <nop,nop,timestamp 3714635203 501752> > > > > > Hi far. > For the agnx card, google send fin packet because after finished three > handshake, it wait for a while but still can't receive the http > request from the client, so it think this tcp session is timeout, > hence it sent the fin packet to terminal this tcp session, but in > above situation google get the correctly http request after three > handshake, so it will not send fin packet. > > lyb > |
|
From: YanBo <dre...@gm...> - 2007-12-23 06:03:27
|
On Dec 23, 2007 12:45 PM, far seer <se...@gm...> wrote: > YanBo, > Below is tcpdump report, though google does not send fin package after three > handshake. > > 12:41:19.157286 IP 192.168.1.122.50637 > jp-in-f147.google.com.http: S > 2707899440:2707899440(0) win 5840 <mss 1460,sackOK,timestamp 500377 > 0,nop,wscale 4> > 12:41:19.267147 IP jp-in-f147.google.com.http > 192.168.1.122.50637: S > 3578420469:3578420469(0) ack 2707899441 win 5672 <mss 1430,sackOK,timestamp > 3714633827 500377,nop,wscale 6> > 12:41:19.267183 IP 192.168.1.122.50637 > jp-in-f147.google.com.http: . ack 1 > win 365 <nop,nop,timestamp 500487 3714633827> > 12:41:20.267347 IP 192.168.1.122.50637 > jp-in-f147.google.com.http: P > 1:32(31) ack 1 win 365 <nop,nop,timestamp 501487 3714633827> > 12:41:20.377030 IP jp-in-f147.google.com.http > 192.168.1.122.50637: . ack > 32 win 89 <nop,nop,timestamp 3714634938 501487> > 12:41:20.419030 IP jp-in-f147.google.com.http > 192.168.1.122.50637: . > 1:1419(1418) ack 32 win 89 <nop,nop,timestamp 3714634974 501487> > 12:41:20.419041 IP 192.168.1.122.50637 > jp-in-f147.google.com.http: . ack > 1419 win 546 <nop,nop,timestamp 501639 3714634974> > 12:41:20.424256 IP jp-in-f147.google.com.http > 192.168.1.122.50637: . > 1419:2837(1418) ack 32 win 89 <nop,nop,timestamp 3714634974 501487> > 12:41:20.424291 IP 192.168.1.122.50637 > jp-in-f147.google.com.http: . ack > 2837 win 727 <nop,nop,timestamp 501644 3714634974> > 12:41:20.428219 IP jp-in-f147.google.com.http > 192.168.1.122.50637: P > 2837:4255(1418) ack 32 win 89 <nop,nop,timestamp 3714634974 501487> > 12:41:20.428249 IP 192.168.1.122.50637 > jp-in-f147.google.com.http: . ack > 4255 win 908 <nop,nop,timestamp 501648 3714634974> > 12:41:20.532164 IP jp-in-f147.google.com.http > 192.168.1.122.50637: . > 4255:5673(1418) ack 32 win 89 <nop,nop,timestamp 3714635087 501639> > 12:41:20.532218 IP jp-in-f147.google.com.http > 192.168.1.122.50637: FP > 5673:5675(2) ack 32 win 89 <nop,nop,timestamp 3714635087 501639> > 12:41:20.532279 IP 192.168.1.122.50637 > jp-in-f147.google.com.http : . ack > 5673 win 1089 <nop,nop,timestamp 501752 3714635087> > 12:41:20.532380 IP 192.168.1.122.50637 > jp-in-f147.google.com.http: F > 32:32(0) ack 5676 win 1089 <nop,nop,timestamp 501752 3714635087> > 12:41: 20.643053 IP jp-in-f147.google.com.http > 192.168.1.122.50637: . ack > 33 win 89 <nop,nop,timestamp 3714635203 501752> > > Hi far. For the agnx card, google send fin packet because after finished three handshake, it wait for a while but still can't receive the http request from the client, so it think this tcp session is timeout, hence it sent the fin packet to terminal this tcp session, but in above situation google get the correctly http request after three handshake, so it will not send fin packet. lyb |
|
From: YanBo <dre...@gm...> - 2007-12-22 15:49:59
|
T24gRGVjIDIyLCAyMDA3IDExOjIzIFBNLCBZYW5CbyA8ZHJlYW1mbHkyODFAZ21haWwuY29tPiB3 cm90ZToKPgo+IE9uIERlYyAyMiwgMjAwNyAxMDo0MyBQTSwgZmFyIHNlZXIgPHNlZXJmYXJAZ21h aWwuY29tPiB3cm90ZToKPiA+IFlhbkJvLAo+ID4gVGhlIGNvZGUgaW1wbGVtZW50IGEgc2ltcGxl IGh0dHAgcmVxcmVzdCBhbmQgc3VwcG9ydCBkZWxheSB0byBzZW5kIGh0dHAKPiA+IHJlcXVlc3Qg YWZ0ZXIgY29ubmVjdCB0byBzaXRlLgo+ID4gTm9ybWFsIHJ1bjogLi9odHRwX2dldCB3d3cuZ29v Z2xlLmNvbQo+ID4gRGVsYXkgcnVuOiAuL2h0dHBfZ2V0IGQgd3d3Lmdvb2dsZS5jb20KPiA+Cj4K PiBoaSBmYXIgc2Vlcgo+Cj4gQmVsb3cgaXMgdGhlIHJlc3VsdCBJIGdvdDoKPgo+IC4vaHR0cF9n ZXQgIGQgd3d3Lmdvb2dsZS5jb20KPiBEZWxheSBzZW5kIHJlcXVlc3QuCj4gV2FybmluZzogVVJM IGlzIG5vdCBpbiBmb3JtYXQgPHNjaGVtZT46Ly88aG9zdD4vPHBhdGg+Lgo+IEFzc3VtaW5nIHNj aGVtZSA9IGh0dHAuCj4gV2FybmluZzogbm8gc2xhc2ggY2hhcmFjdGVyIGFmdGVyIHRoZSBob3N0 IG5hbWUuICBFbXB0eSBwYXRoLiAgQWRkaW5nIHNsYXNoLgo+IFVSTCBzY2hlbWUgPSBodHRwCj4g VVJMIGhvc3QgPSB3d3cuZ29vZ2xlLmNvbQo+IFVSTCBwb3J0ID0gODAKPiBVUkwgcGF0aCA9IC8K PiBDb25uZWN0ZWQgdG8gd3d3Lmdvb2dsZS5jb206ODAKPiBTZW5kaW5nIHJlcXVlc3QuLi4KPiBz bGVlcC4uLgo+IC0tLS0tIEhUVFAgcmVwbHkgaGVhZGVyIGZvbGxvd3MgLS0tLS0KPiBDb25uZWN0 aW9uIGNsb3NlZC4KPiBUb3RhbCBvZiAwIGJ5dGVzIHJlYWQgaW4gMC4xOTM0IHNlY29uZHMKPgo+ ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09Cj4KPiAuL2h0dHBfZ2V0IHd3dy5nb29nbGUuY29tCj4g V2FybmluZzogVVJMIGlzIG5vdCBpbiBmb3JtYXQgPHNjaGVtZT46Ly88aG9zdD4vPHBhdGg+Lgo+ IEFzc3VtaW5nIHNjaGVtZSA9IGh0dHAuCj4gV2FybmluZzogbm8gc2xhc2ggY2hhcmFjdGVyIGFm dGVyIHRoZSBob3N0IG5hbWUuICBFbXB0eSBwYXRoLiAgQWRkaW5nIHNsYXNoLgo+IFVSTCBzY2hl bWUgPSBodHRwCj4gVVJMIGhvc3QgPSB3d3cuZ29vZ2xlLmNvbQo+IFVSTCBwb3J0ID0gODAKPiBV UkwgcGF0aCA9IC8KPiBDb25uZWN0ZWQgdG8gd3d3Lmdvb2dsZS5jb206ODAKPiBTZW5kaW5nIHJl cXVlc3QuLi4KPiAtLS0tLSBIVFRQIHJlcGx5IGhlYWRlciBmb2xsb3dzIC0tLS0tCj4gQ29ubmVj dGlvbiBjbG9zZWQuCj4gVG90YWwgb2YgMCBieXRlcyByZWFkIGluIDAuNDYgc2Vjb25kcwo+Cj4K PgpUaGUgaHR0cCByZXF1ZXN0IHByb2Nlc3Mgd2hlbiBhY2Nlc3MgYW5vdGhlciB3ZWJzaXRlIHd3 dy5iYWlkdS5jb206CgogLi9odHRwX2dldCBkIHd3dy5iYWlkdS5jb20KRGVsYXkgc2VuZCByZXF1 ZXN0LgpXYXJuaW5nOiBVUkwgaXMgbm90IGluIGZvcm1hdCA8c2NoZW1lPjovLzxob3N0Pi88cGF0 aD4uCkFzc3VtaW5nIHNjaGVtZSA9IGh0dHAuCldhcm5pbmc6IG5vIHNsYXNoIGNoYXJhY3RlciBh ZnRlciB0aGUgaG9zdCBuYW1lLiAgRW1wdHkgcGF0aC4gIEFkZGluZyBzbGFzaC4KVVJMIHNjaGVt ZSA9IGh0dHAKVVJMIGhvc3QgPSB3d3cuYmFpZHUuY29tClVSTCBwb3J0ID0gODAKVVJMIHBhdGgg PSAvCkNvbm5lY3RlZCB0byB3d3cuYmFpZHUuY29tOjgwClNlbmRpbmcgcmVxdWVzdC4uLgpzbGVl cC4uLgotLS0tLSBIVFRQIHJlcGx5IGhlYWRlciBmb2xsb3dzIC0tLS0tCkhUVFAvMS4xIDIwMCBP SwpEYXRlOiBTYXQsIDIyIERlYyAyMDA3IDE1OjQ2OjI1IEdNVApTZXJ2ZXI6IEJXUy8xLjAKQ29u dGVudC1MZW5ndGg6IDMwMjIKQ29udGVudC1UeXBlOiB0ZXh0L2h0bWwKQ2FjaGUtQ29udHJvbDog cHJpdmF0ZQpFeHBpcmVzOiBTYXQsIDIyIERlYyAyMDA3IDE1OjQ2OjI1IEdNVApTZXQtQ29va2ll OiBCQUlEVUlEPTAwRkNBMERFNjVDQzA5M0NBNTZGMjVCNkU5QTA0RERCOyBleHBpcmVzPVNhdCwg MjItRGVjLTM3CjE1OjQ2OjI1IEdNVDsgcGF0aD0vOyBkb21haW49LmJhaWR1LmNvbQoKLS0tLS0g SFRUUCByZXBseSBoZWFkZXIgZW5kIC0tLS0tCjxodG1sPjxoZWFkPjxtZXRhIGh0dHAtZXF1aXY9 Q29udGVudC1UeXBlCmNvbnRlbnQ9InRleHQvaHRtbDtjaGFyc2V0PWdiMjMxMiI+PHRpdGxlPu+/ vdm277+90rvvv73Co++/ve+/ve+/ve+/ve+/vdaq77+977+9CjwvdGl0bGU+PHN0eWxlPmJvZHl7 bWFyZ2luOjRweAowfXB7bWFyZ2luOjA7cGFkZGluZzowfWltZ3tib3JkZXI6MH10ZCxwLCN1e2Zv bnQtc2l6ZToxMnB4fSNiLCN1LCNsCnRkLGF7Zm9udC1mYW1pbHk6YXJpYWx9I2t3e2ZvbnQ6MTZw eApWZXJkYW5hO2hlaWdodDoxLjc4ZW07cGFkZGluZy10b3A6MnB4fSNie2hlaWdodDozMHB4O3Bh ZGRpbmctdG9wOjRweH0jYiwjYgphe2NvbG9yOiM3N2M7Zm9udC1zaXplOjEycHh9I3V7cGFkZGlu Zy1yaWdodDoxMHB4O2xpbmUtaGVpZ2h0OjE5cHg7dGV4dC1hbGlnbjpyaWdodDttYXJnaW4tYm90 dG9tOjNweAohaW1wb3J0YW50O21hcmdpbi1ib3R0b206MTBweH0jc2J7aGVpZ2h0OjJlbTt3aWR0 aDo1LjZlbX0ja217aGVpZ2h0OjUwcHh9I2ttCmF7Zm9udC1mYW1pbHk677+977+977+977+9fSNs e21hcmdpbi1ib3R0b206NXB4fSNte21hcmdpbi1sZWZ0OjEwMHB4O3dpZHRoOjIyLjFlbTt0ZXh0 LWFsaWduOmNlbnRlcn1wLCNiLHRhYmxle3dpZHRoOjYwMHB4O2JvcmRlcjowfSNzYiwja20sI2ws I217Zm9udC1zaXplOjE0cHh9I20KYSwjbSBie21hcmdpbi1yaWdodDoxLjE0ZW19YXtjb2xvcjoj MDBjfWE6YWN0aXZle2NvbG9yOiNmNjB9PC9zdHlsZT48L2hlYWQ+Cjxib2R5PjxkaXYgaWQ9dT48 L2Rpdj48Y2VudGVyPjxhIGhyZWY9aHR0cDovL2hpLmJhaWR1LmNvbS9iYWlkdQp0YXJnZXQ9X2Js YW5rPjxpbWcgc3JjPWh0dHA6Ly93d3cuYmFpZHUuY29tL2ltZy9sb2dvLmdpZiB3aWR0aD0xNzQg aGVpZ2h0PTU5CmFsdD0i77+977+977+9y73vv73vv73vv70g77+92bbIv9W877+9Ij48L2E+PGJy Pjxicj48YnI+PGJyPjx0YWJsZSBjZWxscGFkZGluZz0wIGNlbGxzcGFjaW5nPTAKaWQ9bD48dHI+ PHRkIGFsaWduPWxlZnQ+PGRpdiBpZD1tPjxhIG9uY2xpY2s9cyh0aGlzKQpocmVmPWh0dHA6Ly9u ZXdzLmJhaWR1LmNvbT7vv73vv70mbmJzcDvvv73vv708L2E+PGI+77+977+9Jm5ic3A70rM8L2I+ PGEgb25jbGljaz1zKHRoaXMpCmhyZWY9aHR0cDovL3RpZWJhLmJhaWR1LmNvbT7vv73vv70mbmJz cDvvv73vv708L2E+PGEgb25jbGljaz1zKHRoaXMpCmhyZWY9aHR0cDovL3poaWRhby5iYWlkdS5j b20+1qombmJzcDvvv73vv708L2E+PGEgb25jbGljaz1zKHRoaXMpCmhyZWY9aHR0cDovL21wMy5i YWlkdS5jb20+TVAzPC9hPjxhIG9uY2xpY2s9cyh0aGlzKQpocmVmPWh0dHA6Ly9pbWFnZS5iYWlk dS5jb20+zbwmbmJzcDvGrDwvYT48L2Rpdj48L3RkPjwvdHI+PC90YWJsZT4KPHRhYmxlIGNlbGxw YWRkaW5nPTAgY2VsbHNwYWNpbmc9MD48dHIgdmFsaWduPXRvcD48dGQgd2lkdGg9OTI+PC90ZD48 dGQKaGVpZ2h0PTYyIG5vd3JhcD48Zm9ybSBuYW1lPWYgYWN0aW9uPS9zPjxpbnB1dCB0eXBlPXRl eHQgbmFtZT13ZCBpZD1rdyBzaXplPTM2Cm1heGxlbmd0aD0xMDA+PHNjcmlwdD52YXIKdz1kb2N1 bWVudC5mLndkO3cuZm9jdXMoKTtkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgidSIpLmlubmVySFRN TD0nPGEKaHJlZj0iaHR0cDovL3Bhc3Nwb3J0LmJhaWR1LmNvbS8/bG9naW4mdHBsPW1uJnU9Jytl c2NhcGUobG9jYXRpb24uaHJlZikrJyI+77+977+9wrw8L2E+JztmdW5jdGlvbgpzKG8pe2lmKHcu dmFsdWUubGVuZ3RoPjApe3ZhciBoPW8uaHJlZjt2YXIKcT1lbmNvZGVVUklDb21wb25lbnQody52 YWx1ZSk7aWYoaC5pbmRleE9mKCJxPSIpIT0tMSl7by5ocmVmPWgucmVwbGFjZShuZXcKUmVnRXhw KCJxPVteJiRdKiIpLCJxPSIrcSl9ZWxzZXtvLmhyZWYrPSI/cT0iK3F9fX07KGZ1bmN0aW9uKCl7 aWYobmV3ClJlZ0V4cCgicT0oW14mXSspIikudGVzdChsb2NhdGlvbi5zZWFyY2gpKXt3LnZhbHVl PWRlY29kZVVSSUNvbXBvbmVudChSZWdFeHAuJDEpfX0pKCk8L3NjcmlwdD48aW5wdXQKdHlwZT1o aWRkZW4gbmFtZT1jbCB2YWx1ZT0zPiAgPGlucHV0IHR5cGU9c3VibWl0IHZhbHVlPe+/vdm277+9 0rvvv73vv70KaWQ9c2I+PGJyPjxicj48L2Zvcm0+PC90ZD48dGQgd2lkdGg9MTAwPjxhCmhyZWY9 L3NlYXJjaC9qaXFpYW8uaHRtbD7vv73vv73vv73vv708L2E+PGJyPjxhCmhyZWY9L2dhb2ppL2Fk dmFuY2VkLmh0bWw+77+937zvv708L2E+PC90ZD48L3RyPjwvdGFibGU+CjxwIGlkPWttPiZuYnNw OzxhIGhyZWY9aHR0cDovL2hpLmJhaWR1LmNvbT7vv73VvO+/vTwvYT4mbmJzcDt8Jm5ic3A7PGEK aHJlZj1odHRwOi8vd3d3LmJhaWR1LmNvbS9tb3JlPu+/ve+/ve+/ve+/vT4+PC9hPjwvcD4KPHAg c3R5bGU9aGVpZ2h0OjYwcHg+PC9wPgo8cCBzdHlsZT1oZWlnaHQ6MzBweD48YSBvbkNsaWNrPSJ0 aGlzLnN0eWxlLmJlaGF2aW9yPSd1ckNvbm5lY3Rpb24gY2xvc2VkLgpUb3RhbCBvZiAzMzI0IGJ5 dGVzIHJlYWQgaW4gMC4yNDQ0MCBzZWNvbmRzCmwoI2RlZmF1bHQjaG9tZXBhZ2UpJzt0aGlzLnNl dEhvbWVQYWdlKCdodHRwOi8vd3d3LmJhaWR1LmNvbScpIgpocmVmPWh0dHA6Ly91dGlsaXR5LmJh aWR1LmNvbS90cmFmL2NsaWNrLnBocD9pZD0yMTUmdXJsPWh0dHA6Ly93d3cuYmFpZHUuY29tPu+/ vdGw2bbvv73vv73vv73Oqu+/ve+/vdKzPC9hPjwvcD48cApzdHlsZT1oZWlnaHQ6MTRweD48YSBo cmVmPWh0dHA6Ly9qaW5namlhLmJhaWR1LmNvbT7vv73vv73Ste+/vca577+9PC9hPiB8IDxhCmhy ZWY9aHR0cDovL3RvcC5iYWlkdS5jb20+77+977+977+977+977+977+977+9xrDvv708L2E+IHwg PGEgaHJlZj0vaG9tZS5odG1sPu+/ve+/ve+/vdqw2bbvv708L2E+IHwgPGEKaHJlZj1odHRwOi8v aXIuYmFpZHUuY29tPkFib3V0IEJhaWR1PC9hPjwvcD48cCBpZD1iPiZjb3B5OzIwMDcgQmFpZHUg PGEKaHJlZj1odHRwOi8vd3d3LmJhaWR1LmNvbS9kdXR5Psq577+9w7DZtu+/vcew77+92Lbvv708 L2E+IDxhIGhyZWY9aHR0cDovL3d3dy5taWliZWlhbi5nb3YuY24KdGFyZ2V0PV9ibGFuaz7vv73v v71JQ1DWpDAzMDE3M++/ve+/vTwvYT4gPGEKaHJlZj1odHRwOi8vd3d3LmhkMzE1Lmdvdi5jbi9i ZWlhbi92aWV3LmFzcD9iaWFuaGFvPTAxMDIwMjAwMTA5MjUwMDQxMj48aW1nCnNyYz1odHRwOi8v Z2ltZy5iYWlkdS5jb20vaW1nL2dzLmdpZj48L2E+PC9wPjwvY2VudGVyPjwvYm9keT48L2h0bWw+ PCEtLWNhYjhhNGRkZmVhYjdkYzItLT4K |
|
From: YanBo <dre...@gm...> - 2007-12-22 15:23:38
|
On Dec 22, 2007 10:43 PM, far seer <se...@gm...> wrote: > YanBo, > The code implement a simple http reqrest and support delay to send http > request after connect to site. > Normal run: ./http_get www.google.com > Delay run: ./http_get d www.google.com > hi far seer Below is the result I got: ./http_get d www.google.com Delay send request. Warning: URL is not in format <scheme>://<host>/<path>. Assuming scheme = http. Warning: no slash character after the host name. Empty path. Adding slash. URL scheme = http URL host = www.google.com URL port = 80 URL path = / Connected to www.google.com:80 Sending request... sleep... ----- HTTP reply header follows ----- Connection closed. Total of 0 bytes read in 0.1934 seconds ================================================================================ ./http_get www.google.com Warning: URL is not in format <scheme>://<host>/<path>. Assuming scheme = http. Warning: no slash character after the host name. Empty path. Adding slash. URL scheme = http URL host = www.google.com URL port = 80 URL path = / Connected to www.google.com:80 Sending request... ----- HTTP reply header follows ----- Connection closed. Total of 0 bytes read in 0.46 seconds lyb |
|
From: Li Y. <dre...@gm...> - 2007-11-14 10:07:32
|
Hi Michael
Base on we talked early, some problems have been fixed except replace
the calibrate timer with mac80211 workqueue, for the calibrate doesn't
work this moment, hence I'll fixed it later . :)
the git repository at:
http://git.sipsolutions.net/agnx.git
Agnx: Move alloc rings from function Probe to Start.
Agnx: Change spin_lock_irqsave to spin_lock in the interrupt context.
Agnx: Delete the line judge the dev_id is NULL
Agnx: Just reinit tx packet that success sent in handle_tx
Regards
Li YanBo
|
|
From: Li Y. <dre...@gm...> - 2007-10-17 01:23:05
|
Test. |
