Re: Http server implementation for Windows Media Server

On that level ( protocol driver ) that already extra raw data even not
sockets :) and goes out of normal stream at all
Arkady

"Gur" <gur@xxxxxxxxxxx> wrote in message
news:u%23F4KVL2HHA.728@xxxxxxxxxxxxxxxxxxxxxxx
Thanks.,
Actually I used the send_packet feature of WinPcap but I think that a
similar problem applies to me as would happen with raw sockets. Now I
think
that this feature is not relevant to tcp but only to udp or similar
protocols.

Regards

Gur
"Alexander Nickolov" <agnickolov@xxxxxxxx> wrote in message
news:#F6nGjG2HHA.5740@xxxxxxxxxxxxxxxxxxxxxxx
You'd be much better off recording the TCP-level data instead
of the raw packets. I'm assuming you are using a raw TCP
socket. Dump that idea and use a regular TCP socket instead.

To answer your question, the packets aren't ACKed because
they are all discarded as lying outside the TCP window for the
current TCP connection (due to your sequence number mismatch).

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnickolov@xxxxxxxx
MVP VC FAQ: http://vcfaq.mvps.org
=====================================

"Gur" <gur@xxxxxxxxx> wrote in message
news:%23xmNAkB2HHA.5360@xxxxxxxxxxxxxxxxxxxxxxx
In the previous post I forgot to indicate a very important fact - that
is,
the client (which is a Windows Media Player) doesn't ACKs the above
packets
which it should, since my Http server simulates for him a Windows Media
Server and sends the original packets with the slight modification of
a
modified port.

Regards

Gur

"Gur" <gur@xxxxxxxxx> wrote in message
news:e3l18aA2HHA.1208@xxxxxxxxxxxxxxxxxxxxxxx
I do it inside the Http server code. As described in the first post,
the
Http server reads packets one by one from the dump, sending them to
the
client after modifying tcp parameters like addresses, ports etc. In
this
case everything left unchanged but the port, and the "relative
sequence
number" jumps to a huge value.
Regards

Gur

"Arkady Frenkel" <arkadyf@xxxxxxxxxxxxxxxx> wrote in message
news:eNrISB$1HHA.4880@xxxxxxxxxxxxxxxxxxxxxxx
Where do you do(modify) it ?
Arkady

"Ronny" <ronny@xxxxxxxxxxx> wrote in message
news:uR9ltw%231HHA.5772@xxxxxxxxxxxxxxxxxxxxxxx
Thanks,
I think I understand a bit more following your direction...
Now to a real case that I encounter, as described in the first
post
of
this
thread, modifying in the tcp packet before transmitting, just the
port
of
the client as the port is usually different than the original one,
causes
a
real time sniffer to indicate a huge "relative sequence number".
Leaving
it
without modification causes an indication of 1 - just as it was in
the
original packet. Why should the port value influence on that?
Can you explain that?

Regards

Gur
"Arkady Frenkel" <arkadyf@xxxxxxxxxxxxxxxx> wrote in message
news:OSB8$$y1HHA.5884@xxxxxxxxxxxxxxxxxxxxxxx
On the tcp layer, both server's and client's tcpip stack do that
Arkady
"Gur" <gur@xxxxxxxxx> wrote in message
news:eGqSoat1HHA.484@xxxxxxxxxxxxxxxxxxxxxxx
Thanks,
Suppose a common scenario where a standard Web Server responds
to
a
GET
Http request. Does the server ever ACKs the client and when?

Thanks

Gur
"Arkady Frenkel" <arkadyf@xxxxxxxxxxxxxxxx> wrote in message
news:uystfhs1HHA.1204@xxxxxxxxxxxxxxxxxxxxxxx
That strange that no ACK appear because any data should be
ACKed
Arkady

"Gur" <gur@xxxxxxxxx> wrote in message
news:ukd9yIq1HHA.1336@xxxxxxxxxxxxxxxxxxxxxxx
Hi all,

I'm trying to implement a specific Http server that listens
on
port
8080
(not the standard 80). Actually it resembles a Windows Media
Server
that
also works as a HTTP server (among some other modes).
I have a dump file of prercorded transmision from an actual
Window
Media
Server and Windows Media Player, and my server implementation
should
transmit them after establishing the tcp connection with the
Player.
In reality, the connection is established but the server
behaves
with
the following anomalies-
1. After the "GET" transaction by the Player, the server
transmits
an
ACK which doen't appear in the normal case.
2. The first dump packet that is being transmitted starts
with
a
huge
"Realtive Sequence Number" instead of a 1.

Can someone advise please?

Regards

Gur





















.

Relevant Pages

  • Re: KB893066 kills ftp
    ... "Networking programs that send TCP packets or UDP packets over raw IP ... sockets may stop working after you apply security update MS05-019 to a ... "If you frequently use tools that send packets over raw sockets, ...
    (microsoft.public.windowsupdate)
  • Re: ipfw uid/gid to match listening TCP sockets?
    ... the traffic goes to a listening TCP socket. ... The only peculiarity I can see now is that listening sockets shouldn't generate outbound traffic; as soon a 3-way handshake starts, ... I'm not sure I agree with your analysis that listen sockets don't generate packets, btw: the syncache generates packets that are not yet from a specific socket, so arguably they are from the listen socket. ...
    (freebsd-net)
  • Re: ipfw uid/gid to match listening TCP sockets?
    ... the traffic goes to a listening TCP socket. ... it is OK for UDP to match PCBs (essentially sockets) with a wildcard ... match inbound packets only. ...
    (freebsd-net)
  • Re: [RFC][PATCH 0/9] Network receive deadlock prevention for NBD
    ... NFS over UDP - remote side will not stop sending just because receiving socket code drops data due to OOM, or IPsec or compression, which can ... those NFS packets that belong to the critical mount), ... can take up memory right at the time you don't have any extra ... onto data for non-critical sockets, ...
    (Linux-Kernel)
  • Re: Error in send, while using IP_HDRINCL
    ... > Arkady Frenkel wrote: ... >>> And MS could do exactly the same precautions for an app that uses raw ... >>> sockets. ...
    (microsoft.public.win32.programmer.networks)