Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 3 years ago.
Improve this question
Standard Ethernet has no error correction. If FCS doesn't check out fine, the frame is dropped with no further effort.
Ethernet doesn't notify the switch at the other end of the link that it
is dropping the packet, something like ICMP of IP, neither does it ask for retransmission.
Isn't that a bit odd? One would have guessed a retransmission mechanism right when an error comes up-- before it propagates, without burdening the higher levels with overhead due to this.
In TCP for instance, a packet loss in Ethernet layer is likely to cause
destination buffer overflows due to gaps in the byte sequence, and from there retransmission of dropped segments due to this lack of buffer space, which is a much bigger waste of resources than fixing it right at the link layer.
TIA.
//=================================
EDIT:
The Q here is:
Why doesn't Ethernet have a retransmission mechanism when there is a CRC error? That is,
when the receiving switch sees an error on the frame, why doesn't the it
ask the sending switch at the other end of the link to retransmit the frame? Or doesn't even just notify the sender?
Ethernet is just dropping the packets whenever there are such errors. Without any retransmission or notification, the packet loss won't be discovered
until some other control mechanism in an upper layer protocol.
Wouldn't it be a sound logic to make Ethernet at least notify the sender? Is retransmission overhead the only reason for
not having an elaborate error handling?
Remember Ethernet isn't point-to-point. If an ethernet packet is corrupted, how can you tell who to send the failure message to?
The BER for Ethernet is very very low typically of the order of 10^(-10).
So the overhead for ACKing each frame would get higher than just ignoring errors and let upper layers handle if there is need.
Ok, you won't see it very much any more.... But in a half-duplex ethernet enviroment (csma/cd) packets will be resent if a collision is detected by the transmitting stations.
Related
Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 3 years ago.
Improve this question
I am currently playing with esp8266. It is connected to arduino via software COM port. Arduino is sending AT commands and esp is sending responses back.
The problem is that small responses look absolutely normal but longer ones are kind of damaged. First I thought this was because poor wiring but problem remained after correcting it. Also long responses are always corrupted after certain point and there is not absolute garbage but something looking slightly like correct thing:
AT+CWLAP
+CWLAP:(3,"MGTS_GPON_1936",-81,"94:4a:0c:44:8d:58",0,23,0)
+CWLAP:("::,C"N7:e,Ar8":,C""::,C"-2:0:O-ea,Aa":c,C"5::0LG8,f9):P-9:3Lv8:5,AT68d1
"9":"
458e1
AT+CWLAP
+CWLAP:(4,"Vikus",-60,"f4:6d:04:a0:ee:36",1,40,0)
+CWLAP:(3,"NURIK":55Ae4,803WM_205)PS,30):_,37,Ae9e13+,s-0e0PR,453LT9":,):_"8:1+,"::,+T"::,+,"5:3
busy s...
Recv 4 bytes
SEND OK
+IPD,166:<html>
<head><title>400 Bad Request</title></heaor>r e/
e<<tS
After replacing power supply, arduino, esp module and load capacitor things not changed:
AT+CIPSTART=
"UDP","time1.google.c⸮Kb⸮⸮⸮j
0,CONNECT
OK
AT+CIPSE
ND=48
OK
>
Secv 48 cytes
SE
ND OK
+RE⸮⸮⸮⸮"
⸮
AT+CWLAP
+CWLAP:(3,"NUR
IK",-74,"38:2c:4a:98:85:4f",1,0,0)
+CWLAP:(4,"MGT_P96,4":8b:::
8"18⸮⸮⸮*A⸮B⸮b⸮U⸮⸮͡⸮⸮⸮ʲ⸮⸮%⸮х⸮⸮⸮bkʂb2⸮⸮⸮⸮*⸮颊҂⸮Ҫ⸮b⸮b⸮
Ғ*⸮⸮bb⸮b⸮Jj
+CWLP3"oOK0"7,04:::8a080
⸮*A⸮B⸮b⸮⸮k⸮͉bj⸮b2Ѳ
Looks like a bus clock mismatch or corrupt RAM. Can you replace each side at a time with the same hardware?
Also check out your power supply.
Corruption in long messages also may be the indicator of inadequate load support capacitors.
The reason is Arduino's Software serial can't properly work on 115200 baud rate needed to communicate to esp8266. To fix this you have to send command AT+UART_DEF=9600,8,1,0,0 to change esp baud rate and after that change SoftwareSerial speed to 9600.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
Before a browser can request for a webpage, A TCP connection is required to be established. What is the necessity of 3 way handshake in interacting with a server computer? why can't we simply send a web request and wait for the response?
Shouldn't the resolution of IP address be enough for this purpose?
Basically, I need to know the reason for establishing TCP connection.
thanks in advance
You are using a device named A and server is named B
Host A sends a TCP SYNchronize packet to Host B
Host B receives A's SYN
Host B sends a SYNchronize-ACKnowledgement
Host A receives B's SYN-ACK
Host A sends ACKnowledge
Host B receives ACK.
TCP socket connection is ESTABLISHED.
See more at: http://www.inetdaemon.com/tutorials/internet/tcp/3-way_handshake.shtml#sthash.F2f4b8Xn.dpuf
Because you need a TCP connection to send HTTP over, and TCP has a 3-way handshake.
Basically, I need to know the reason for establishing TCP connection.
Because HTTP runs over TCP. It doesn't exist in a vacuum.
TCP provides ordering, automatic retransmission, and congestion control. I'd say these are the obvious reasons why the design adopted TCP.
In contrast, e.g. UDP is fast. There is no handshaking. But UDP packets are not ordered, also packets can get lost (no automatic retransmission), and there is no congestion control.
You can try implementing your data transferring for things like HTML in UDP. It's not easy, you still need to reinvent ordering and retransmission for reliable lossless delivery.
If you don't care about lossy or a bit out-of-order transferring then you probably don't need TCP. (e.g. real time video)
--
On the other hand, avoid TCP to get better performance is not necessarily a bad idea. Read about QUIC. (It also has features like loss recovery and congestion control, you should not expect it to be extremely lightweight.)
Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 11 days ago.
Improve this question
What I want to understand is how to determine clients that associated/connected to an AP using network traffic.
For clarification: I am not connected to the network. I am using a usb card on monitor mode and capturing traffic using wireshark. I choose some AP I saw on the traffic and filtered all traffic relevant to it. I am trying to understand, using this data, what clients are connected to this AP.
Hope you guys understand what I mean.
You should look for the association request and association response 802.11 packets in your sniffed list. Basically, client sends the association request and AP replies with the response (you can parse the response according to the 802.11 to find out whether association was granted or rejected. The client will normally be connected to the AP until deauthentication packet arrives from the AP.
From what I know, there's no way to ask the AP for all connected clients unless you are the administrator of the AP but you wouldn't be listenning to the connection wouldn't you ? ;)
However, you can listen to all traffic relevant to this AP and try to determine wheter the captured packet is doing real business (fetching url, ftp, etc.) or just noise. This way, you can safely say that this given IP address is connected to the AP or not.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I am trying to understand TCP congestion avoidance mechanism, but I don't understand one thing:
TCP congestion avoidance is per flow or per link?
In other words: there are 2 routers A and B
A is sending B two TCP flows - when one TCP flow detects congestion, does it decrease window size in the other flow as well?
of course if this happens, the other flow will detect congestion in some time, but does the second flow "waits" until it detects congestion on its own? that would be quite uneffective...
thanks a lot
It decreases the window size for the current connection. Each connection's RTT and windows are maintained independently.
Routers operate on layer 3 (IP) and are not aware of layer 4 (TCP), because of this, routers do not take any part in TCP congestion avoidance mechanism. This mechanism is fully implemented by TCP endpoints. It is triggered by routers dropping IP packets, but (classic) routers are not aware what higher level protocol IP packets carry.
The fact that one flow does not affect the other is quite desirable from the security perspective. With NAT you can have many hosts sharing the same IP address. From the outside world all these hosts look as a single machine. So, if some server reduced throughput of all TCP connections coming from a single IP address in response to packets dropped within one of those connections that would open a door to quite nasty DoS attacks.
Another issue is that some routers may be configured to drop packets based on IP ToS field. For example, latency sensitive SSH traffic may set different ToS than bulk FTP download. If router is configured to take into account ToS field, it may drop packets belonging to FTP connection, which should trigger congestion avoidance, but is should not affect packets belonging to SSH connection, which may be handled with higher priority.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 3 years ago.
Improve this question
I want to connect two computer via serial but for each to see each other via a TCP/IP connection. Ie, create new network device on the computers that are in actual fact serial ports.
The reason for this is that I am actually testing the medium in which the serial connection is made (wireless), and part of the experiment will be to use TCP/IP.
The radio being tested is a telemetry radio for use in low power applications. It polls once a second, sending data out on the wireless channel every poll when something has been received via the serial port. It uses a Modbus RTU delimiter to determine the end of data coming in on the serial port.
slip and ppp are more suitable for use with actual serial modems from what I understand.
This is actually a very hard problem. TCP/IP is a very chatty protocol and you will have problems with the radio system you have described because of the pattern of packets and ACKs you will have. In the past for some similarly unsuited applications I worked on a system that fibbed about the TCP/IP connection by faking some packets while pushing the data over a link like you have.
It is a pain, but we were doing it to support sshing over a totally inappropriate channel (high loss and high latency with moving endpoints) but it worked.
SLIP (Serial Line IP) sounds like something you might want to look into for this project.
you may use Simple TCP/IP, UDP connection by using UART using a software like this:
http://www.serialporttool.com/CommTunnel.htm