Regarding DHCP...
There are only four packets transferred: DISCOVER, (700ms delay), OFFER, REQUEST, (700ms delay), ACK. There is no NACK, and no retries for resending DISCOVER/REQUEST with same or different parameters.
This is the problem with doing captures on only one end: you don't know "truly" what end is responsible for the 700ms delay. How soon after the client sends the DISCOVER does the server see said packet? The server might be seeing the packet immediately, but then screwing around for 700ms before sending back a response. Same goes for REQUEST.
The lack of long delay between OFFER and REQUEST might shed some light on things too, but it's semi-speculative: DISCOVER and REQUEST are both things sent by the client. So if the problem is WiFi-level, the issue might be specific to *sending* (outbound traffic from the DSi), not receiving (inbound traffic to the DSi).
Spending a lot of time on this isn't worth it until you can get another (non-Nintendo) 802.11-based device on your network and see if it behaves identically.
But in general: How fast is DHCP under normal circumstances?
An entire DHCP negotiation should complete in milliseconds total. Here, I'll demonstrate. Below captures were done from the DHCP server (which happens to be my router). I did two captures, both using
tcpdump -p -i switch0 -l -n -s 4096 "udp and (port 67 or port 68)" but the latter with
-v for packet decoding. tcpdump's packet decoding is rudimentary (Wireshark does a much better job but I couldn't be arsed to use
-w foo.pcap and then scp off the file to a machine running Wireshark). Client MAC is XXX'd out, but I left everything else in place (don't care that you can see client IPs or my LAN domain name).
Client: Linux Mint 17.3 Rosa x64, using ISC DHCP client 4.2.4. Kernel is Linux 3.19.0 x64
Server: Ubiquiti EdgeRouter X SFP, using ISC DHCP server 4.1-ESV-R8. Kernel is Linux 3.10.107 mips
Code: Select all
11:04:54.271957 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from xx:xx:xx:xx:xx:xx, length 300
11:04:54.272830 IP 192.168.1.1.67 > 192.168.1.52.68: BOOTP/DHCP, Reply, length 302
11:04:54.274967 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from xx:xx:xx:xx:xx:xx, length 300
11:04:54.275867 IP 192.168.1.1.67 > 192.168.1.52.68: BOOTP/DHCP, Reply, length 302
Code: Select all
11:05:41.465904 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from xx:xx:xx:xx:xx:xx:xx, length 300, xid 0x740a5e54, Flags [none]
Client-Ethernet-Address xx:xx:xx:xx:xx:xx:xx
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Hostname Option 12, length 5: "linux"
Parameter-Request Option 55, length 18:
Subnet-Mask, BR, Time-Zone, Default-Gateway
Domain-Name, Domain-Name-Server, Option 119, Hostname
Netbios-Name-Server, Netbios-Scope, MTU, Classless-Static-Route
NTP, Classless-Static-Route, Classless-Static-Route-Microsoft, Static-Route
Option 252, NTP
11:05:41.466735 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 330)
192.168.1.1.67 > 192.168.1.52.68: BOOTP/DHCP, Reply, length 302, xid 0x740a5e54, Flags [none]
Your-IP 192.168.1.52
Client-Ethernet-Address xx:xx:xx:xx:xx:xx:xx
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 192.168.1.1
Lease-Time Option 51, length 4: 86400
Subnet-Mask Option 1, length 4: 255.255.255.0
Default-Gateway Option 3, length 4: 192.168.1.1
Domain-Name Option 15, length 8: "home.lan"
Domain-Name-Server Option 6, length 4: 192.168.1.51
T119 Option 119, length 10: 1128,28525,25859,27745,28160
NTP Option 42, length 4: 192.168.1.51
11:05:41.467099 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from xx:xx:xx:xx:xx:xx:xx, length 300, xid 0x740a5e54, Flags [none]
Client-Ethernet-Address xx:xx:xx:xx:xx:xx:xx
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Server-ID Option 54, length 4: 192.168.1.1
Requested-IP Option 50, length 4: 192.168.1.52
Hostname Option 12, length 5: "linux"
Parameter-Request Option 55, length 18:
Subnet-Mask, BR, Time-Zone, Default-Gateway
Domain-Name, Domain-Name-Server, Option 119, Hostname
Netbios-Name-Server, Netbios-Scope, MTU, Classless-Static-Route
NTP, Classless-Static-Route, Classless-Static-Route-Microsoft, Static-Route
Option 252, NTP
11:05:41.467832 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 330)
192.168.1.1.67 > 192.168.1.52.68: BOOTP/DHCP, Reply, length 302, xid 0x740a5e54, Flags [none]
Your-IP 192.168.1.52
Client-Ethernet-Address xx:xx:xx:xx:xx:xx:xx
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: ACK
Server-ID Option 54, length 4: 192.168.1.1
Lease-Time Option 51, length 4: 86400
Subnet-Mask Option 1, length 4: 255.255.255.0
Default-Gateway Option 3, length 4: 192.168.1.1
Domain-Name Option 15, length 8: "home.lan"
Domain-Name-Server Option 6, length 4: 192.168.1.51
T119 Option 119, length 10: 1128,28525,25859,27745,28160
NTP Option 42, length 4: 192.168.1.51
Could it be just a common thing to have those 700ms delays (or similar) on most or all routers?
The problem with 802.11 in general is often latency, especially on a busy or congested (incl. interference-laden) network. This is why I brought up 2.4GHz vs. 5GHz bands as well. Analysing wireless latency is stupidly painful. I don't have equipment to do it, nor the skill set to do it (it's why there are actual professionals that do *just that*). One of the biggest problems with diagnosing wireless latency too is that classic ICMP
ping is not necessarily a good/reliable tool for it. UDP and TCP packets are often handled very differently by 802.11 APs (meaning they're prioritised in some weird way) compared to ICMP. I'll demonstrate that below.
In my area, 2.4GHz is completely worthless -- it's saturated to the point of it being unusable, due to literally 300+ other APs being around, tons of Bluetooth devices, baby monitors, cordless phones, microwaves, and even a company that seems to have some kind of dish on their rooftop blasting god knows what right over my flat. My neighbours all have the same problem too (and they use different equipment, obviously). 5GHz here is the only usable band if you want stability and speed.
Regarding general 802.11 crap:
This is a ping from an Ethernet client (FreeBSD) issued against my mobile phone (Android/Linux-based). Mobile phone is obviously connected wirelessly to my AP (a Ubiquiti UAP-AC-LITE -- this IS NOT the same device as my router!), using 2.4GHz band (20MHz) (because my phone is so old it lacks 5GHz). Phone IS NOT in sleep/standby mode or anything like that (yes it matters!). The mobile phone reports a signal strength of "excellent" -- which happens to be about -38 dBm -- and a negotiated link speed of 65mbps:
Code: Select all
$ ping 192.168.1.150
PING 192.168.1.150 (192.168.1.150): 56 data bytes
64 bytes from 192.168.1.150: icmp_seq=0 ttl=64 time=31.862 ms
64 bytes from 192.168.1.150: icmp_seq=1 ttl=64 time=41.975 ms
64 bytes from 192.168.1.150: icmp_seq=2 ttl=64 time=107.345 ms
64 bytes from 192.168.1.150: icmp_seq=3 ttl=64 time=26.975 ms
64 bytes from 192.168.1.150: icmp_seq=4 ttl=64 time=28.669 ms
64 bytes from 192.168.1.150: icmp_seq=5 ttl=64 time=4.773 ms
64 bytes from 192.168.1.150: icmp_seq=6 ttl=64 time=111.805 ms
64 bytes from 192.168.1.150: icmp_seq=7 ttl=64 time=1.486 ms
64 bytes from 192.168.1.150: icmp_seq=8 ttl=64 time=40.157 ms
64 bytes from 192.168.1.150: icmp_seq=9 ttl=64 time=65.468 ms
64 bytes from 192.168.1.150: icmp_seq=10 ttl=64 time=83.536 ms
64 bytes from 192.168.1.150: icmp_seq=11 ttl=64 time=111.209 ms
64 bytes from 192.168.1.150: icmp_seq=12 ttl=64 time=2.599 ms
64 bytes from 192.168.1.150: icmp_seq=13 ttl=64 time=29.294 ms
64 bytes from 192.168.1.150: icmp_seq=14 ttl=64 time=63.837 ms
64 bytes from 192.168.1.150: icmp_seq=15 ttl=64 time=81.150 ms
64 bytes from 192.168.1.150: icmp_seq=16 ttl=64 time=101.826 ms
64 bytes from 192.168.1.150: icmp_seq=17 ttl=64 time=75.267 ms
64 bytes from 192.168.1.150: icmp_seq=18 ttl=64 time=37.942 ms
64 bytes from 192.168.1.150: icmp_seq=19 ttl=64 time=62.010 ms
64 bytes from 192.168.1.150: icmp_seq=20 ttl=64 time=25.993 ms
64 bytes from 192.168.1.150: icmp_seq=21 ttl=64 time=47.632 ms
64 bytes from 192.168.1.150: icmp_seq=22 ttl=64 time=48.191 ms
64 bytes from 192.168.1.150: icmp_seq=23 ttl=64 time=46.992 ms
64 bytes from 192.168.1.150: icmp_seq=24 ttl=64 time=110.968 ms
64 bytes from 192.168.1.150: icmp_seq=25 ttl=64 time=33.507 ms
64 bytes from 192.168.1.150: icmp_seq=26 ttl=64 time=53.061 ms
64 bytes from 192.168.1.150: icmp_seq=27 ttl=64 time=67.739 ms
64 bytes from 192.168.1.150: icmp_seq=28 ttl=64 time=89.304 ms
64 bytes from 192.168.1.150: icmp_seq=29 ttl=64 time=113.739 ms
64 bytes from 192.168.1.150: icmp_seq=30 ttl=64 time=98.171 ms
64 bytes from 192.168.1.150: icmp_seq=31 ttl=64 time=90.603 ms
64 bytes from 192.168.1.150: icmp_seq=32 ttl=64 time=89.294 ms
64 bytes from 192.168.1.150: icmp_seq=33 ttl=64 time=105.353 ms
64 bytes from 192.168.1.150: icmp_seq=34 ttl=64 time=33.728 ms
64 bytes from 192.168.1.150: icmp_seq=35 ttl=64 time=45.911 ms
^C
--- 192.168.1.150 ping statistics ---
36 packets transmitted, 36 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.486/61.371/113.739/33.443 ms
The latency you see here is not some delay between the AP and the router or anything like that. Yet, if I was to do a speedtest from this mobile phone using Ookla's Speedtest app (which uses TCP (HTTP) exclusively -- I know, we actually pay thousands a year at my workplace to run their server software on our own servers, so I'm familiar with what it's doing), which tests throughput to the Internet, I get around 46mbit/sec down, 5.7mbit/sec up, claiming a ping of 9ms with 3ms jitter. All of that is because the test behind the scenes is using TCP.
If I changed wireless APs to, say, a consumer router/AP like the Asus RT-AC56U running one of the latest TomatoUSB firmwares using stock wireless driver settings on the AP itself, the above ping numbers are multiplied by about 6 or 7 (i.e. even worse), and Speedtest results drop to something like 600-800kbits/sec. It's literally unusable. Oh, and packet loss tends to go through the roof too.
If I enable interference mitigation at the wireless driver level on that same Asus router/AP, the above numbers should be multiplied by about 2, and packet loss is substantially worse -- i.e. better, but not as good as whatever the Ubiquiti Atheros-based (QCA9563) 802.11 IC or stack is able to do. I'm sorry to say I don't have hard numbers for this because I got rid of that equipment last year and I couldn't be happier.
Anyway, if I do the same test but to a different wireless client and band -- this time, an OS X laptop using the 5GHz band (40MHz too), reporting -36dBM and a negotiated rate of 400mbps -- but everything else is identical, we see similar latency with ping:
Code: Select all
$ ping 192.168.1.151
PING 192.168.1.151 (192.168.1.151): 56 data bytes
64 bytes from 192.168.1.151: icmp_seq=0 ttl=64 time=24.765 ms
64 bytes from 192.168.1.151: icmp_seq=1 ttl=64 time=46.102 ms
64 bytes from 192.168.1.151: icmp_seq=2 ttl=64 time=70.965 ms
64 bytes from 192.168.1.151: icmp_seq=3 ttl=64 time=91.566 ms
64 bytes from 192.168.1.151: icmp_seq=4 ttl=64 time=113.305 ms
64 bytes from 192.168.1.151: icmp_seq=5 ttl=64 time=31.709 ms
64 bytes from 192.168.1.151: icmp_seq=6 ttl=64 time=1.031 ms
64 bytes from 192.168.1.151: icmp_seq=7 ttl=64 time=76.208 ms
64 bytes from 192.168.1.151: icmp_seq=8 ttl=64 time=1.441 ms
64 bytes from 192.168.1.151: icmp_seq=9 ttl=64 time=18.764 ms
64 bytes from 192.168.1.151: icmp_seq=10 ttl=64 time=41.436 ms
64 bytes from 192.168.1.151: icmp_seq=11 ttl=64 time=64.833 ms
64 bytes from 192.168.1.151: icmp_seq=12 ttl=64 time=87.007 ms
64 bytes from 192.168.1.151: icmp_seq=13 ttl=64 time=109.463 ms
64 bytes from 192.168.1.151: icmp_seq=14 ttl=64 time=28.352 ms
64 bytes from 192.168.1.151: icmp_seq=15 ttl=64 time=1.201 ms
64 bytes from 192.168.1.151: icmp_seq=16 ttl=64 time=69.142 ms
64 bytes from 192.168.1.151: icmp_seq=17 ttl=64 time=94.800 ms
64 bytes from 192.168.1.151: icmp_seq=18 ttl=64 time=116.040 ms
64 bytes from 192.168.1.151: icmp_seq=19 ttl=64 time=35.338 ms
64 bytes from 192.168.1.151: icmp_seq=20 ttl=64 time=57.330 ms
64 bytes from 192.168.1.151: icmp_seq=21 ttl=64 time=81.447 ms
64 bytes from 192.168.1.151: icmp_seq=22 ttl=64 time=155.560 ms
64 bytes from 192.168.1.151: icmp_seq=23 ttl=64 time=26.479 ms
64 bytes from 192.168.1.151: icmp_seq=24 ttl=64 time=49.952 ms
64 bytes from 192.168.1.151: icmp_seq=25 ttl=64 time=175.714 ms
64 bytes from 192.168.1.151: icmp_seq=26 ttl=64 time=96.506 ms
64 bytes from 192.168.1.151: icmp_seq=27 ttl=64 time=1.428 ms
64 bytes from 192.168.1.151: icmp_seq=28 ttl=64 time=41.354 ms
64 bytes from 192.168.1.151: icmp_seq=29 ttl=64 time=65.262 ms
64 bytes from 192.168.1.151: icmp_seq=30 ttl=64 time=90.121 ms
64 bytes from 192.168.1.151: icmp_seq=31 ttl=64 time=112.011 ms
64 bytes from 192.168.1.151: icmp_seq=32 ttl=64 time=136.357 ms
64 bytes from 192.168.1.151: icmp_seq=33 ttl=64 time=112.940 ms
64 bytes from 192.168.1.151: icmp_seq=34 ttl=64 time=338.610 ms
64 bytes from 192.168.1.151: icmp_seq=35 ttl=64 time=14.193 ms
64 bytes from 192.168.1.151: icmp_seq=36 ttl=64 time=1.337 ms
^C
--- 192.168.1.151 ping statistics ---
37 packets transmitted, 37 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.031/72.434/338.610/63.063 ms
...but web-based Ookla's Speedtest returns around 180mbit/sec down, 5.7mbit/sec up, with a ping of 13ms and jitter unknown (sad panda).
The "cap" on the speed with OS X is due to my Internet speed. I pay for 150mbps down/5mbps up (but Comcast offers some speed boosting crap that temporarily can increase your downstream speed for short periods of time). When I was paying for 300mbps down/15mbps up, I could literally max the connection out.
I don't have 802.11 interference/noise data for either of these clients, because for whatever reasons vendors of sorts (pick one: Google, Motorola, Apple, or the 802.11 ICs they use) don't usually disclose this information. I'm lucky to get signal strength dBm-based indicators at all.
Regarding TCP:
Nothing to discuss here, I don't see anything relating to TCP or IP stacks.
Regarding whatever ath_create_pstream_cmd_1st is:
This looks like a 802.11 PHY and client negotiation parameters struct, not something relating to TCP. The ath_* naming convention looks to be Atheros-specific stuff combined with uniqueness of some aspect of the DSi. I'll have to defer to other people who have familiarity with this, but to me it really looks like these are 802.11 client settings.
When it comes to 802.11 stacks, however: bps
should stand for
bits per second, unless whoever wrote the documentation meant Bps, which would be an INCREDIBLY bizarre unit to choose. In Broadcom 802.11 APIs, the PHY speed chosen is also in bits. (What is it going to take for people doing this stuff to use proper capitalisation for units, or to just spell out the words like I do, ex. kbits, KBytes, etc. It relieves all confusion!)? The whole "-ibi" suffix thing is absolute nonsense and did nothing but complicate matters too. Sigh.
But yes: 6000000 bits per second = 6 megabits per second = ~750 kilobytes per second. So sure, try tweaking minPhyRate, or see if the driver lets you do something like use a value of 0 to represent auto-negotiated (802.11 client and AP can and will negotiate this, but whether or not that value in the struct can adjust that, I do not know).