It is currently Mon Jul 22, 2019 7:43 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 14 posts ] 
Author Message
PostPosted: Sun Jan 13, 2019 4:18 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 941
I am looking for some performance stats for Wifi and DHCP.

Wifi
Wifi is usually rated in Mbit/s, but I haven't found satisfiying info what that means in practice. Some pages say that one could at best get half of the nominal speed, but it's unclear what that's referring to. For example, in these two cases:
Code:
  PC ------cable----->  AccessPoint - - -wifi- - - > Console

  PC - - - wifi- - - >  AccessPoint - - -wifi- - - > Console
The first case (cable+wifi) should be twice as fast as the second case (wifi+wifi), assuming that both wifi connections are sharing the same channel. If it's true that the "best case" is half speed, then the second case would be only quarter speed?
The other issue that is that half of, say, 54Mbit/s would be 27MBit/s... but what does that mean in bytes? Should one divide 27Mbit/s by 8? Or perhaps by 10 (alike as one would do for serial byte transfers with start+stop bits)? And/or subtract further overload for packet headers and beacons and responses - or is that overload already recursed in the "at best half speed" figure?

What I am doing in practice is uploading a file from PC (via cable to access point), to DSi console (via wifi from access point). The Atheros AR6013 chip in the DSi should support 54Mbit/s. And I think the neigherborhood isn't too crowded (especially there aren't too many night-active people other than myself). Any ideas what optimal upload speed I should expect, in bytes per second?

DHCP
DHCP is obtaining the DNS and local IP address by sending two small packets, and receiving two small response packets, each packet is about 300 bytes, so the total amount is about 1.2Kbyte, which shouldn't cause any noticeable delay. But, in practice, my code takes about 1-2 seconds for getting through the DHCP stuff. Is that normal?
Everything else works ways faster (eg. connecting to the access point, or transferring actual data), it's only DHCP being exceptionally slow, and using different routers or access points doesn't seem to help.


Top
 Profile  
 
PostPosted: Sun Jan 13, 2019 4:29 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8488
Location: Seattle
The canonical DHCP client ... I think per the RFC ... is extremely lethargic about how it works.

I remember an alternative implementation from when wardriving was still a thing that got a lease in a couple tens of milliseconds.


In practice, I just tested and saw 5MB/sec (~40mbit/sec) unidirectional on 2.4GHz 802.11g (i.e. "54mbit/sec") via [PC - 1Gbit ethernet - switch - 1Gbit ethernet - AP - 54 Mbit 802.11g - android].

Now ... given that wikipedia's article on 802.11g says I "shouldn't" be able to get better than 31mbit/sec ... dunno.


Top
 Profile  
 
PostPosted: Sun Jan 13, 2019 5:57 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 941
lidnariq wrote:
The canonical DHCP client ... I think per the RFC ... is extremely lethargic about how it works.

Hmmm, yeah, it's counting timings in units of seconds, and wants you to wait 10 seconds before sending retries. That really doesn't sound as if they had imagined it to work very fast.
On the other hand, skipping through rfc2131, I haven't spotted anything where they are explicitely stating that the router MUST issue huge delays before sending response messages.
Or is there some support for multiple routers handing out IP addresses in DHCP? So that my router would have to wait if any other (non-existing) routers are contributing info about free IP addresses before sending the reply?

lidnariq wrote:
I remember an alternative implementation for when wardriving was still a thing that got a lease in a couple tens of milliseconds.

Do you mean historically, or more recently? I have read about something similar a few years ago, some company developing something for fast moving vehicles hopping from one access point to another, the newspaper article wasn't too specific on technical details, but they might have been referreing to the same problem that I am currently encountering.
As far as I remember they got it down to 50ms or so. I don't know how they were doing that, but I guess the solution would be improving the access point side (so there isn't much that could be done at client side).

If there's no better way to speed-up DHCP, I could eventually memorize the DHCP IP/DNS values in RAM, and re-use that info upon warmboot. There is a "lease time" in DHCP options (rfc1533), so it might be perfectly legal to re-use the values for that duration, even after rebooting the console and re-connecting to the access point.
The "dirty" case would be if somebody resets the router, causing it to forget that it had leased IP addresses.

lidnariq wrote:
In practice, I just tested and saw 5MB/sec (~40mbit/sec) unidirectional on a 2.4GHz 802.11g (i.e. "54mbit/sec") via [PC - 1Gbit ethernet - switch - 1Gbit ethernet - AP - 54 Mbit 802.11g - android].

Good to know, that's about as fast as it should be (and more than what those webpages with "half speed at best" were claiming).
Unfortunately, on the DSi, I am still reaching only 600Kbyte/s max. Although it should be nearly 10x faster than that : /
I've moved the ARM7 code to faster VRAM instead slow Main RAM today, but that didn't help, so the issue might be elsewhere, maybe in the TCP layer (which might be a bit messy, stumbling over its on feet, or, being originally code for NDS, it might just fail to request enough packets per second).


Top
 Profile  
 
PostPosted: Sun Jan 13, 2019 6:31 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8488
Location: Seattle
nocash wrote:
Or is there some support for multiple routers handing out IP addresses in DHCP? So that my router would have to wait if any other (non-existing) routers are contributing info about free IP addresses before sending the reply?
My understanding is that the client does have to deal with multiple offers, but I don't think there's an explicit way for multiple DHCP servers to negotiate who wins.

Quote:
lidnariq wrote:
I remember an alternative implementation for when wardriving was still a thing that got a lease in a couple tens of milliseconds.
Do you mean historically, or more recently?
Very historically. WEP era stuff.

Quote:
maybe in the TCP layer (which might be a bit messy, stumbling over its on feet, or, being originally code for NDS, it might just fail to request enough packets per second).
TCP flows are "supposed" to automatically scale to the available bandwidth, by keeping more packets in flight without acknowledgment at the same time.


Top
 Profile  
 
PostPosted: Sun Jan 13, 2019 8:02 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 941
Do you remember the name of that historical approach, or how it worked, and if it would still work today?

Hmmm, or was it an actual alternate connection protocol at all? Maybe it was just brute-forcing free IP addresses instead of asking for a free IP address. If DHCP is really as slow as it seems to be, then brute-forcing might be actually faster. Alike this: Hello, I'm 192.168.1.5, do you like me? No? Ah, wait, I am 192.168.1.7 and I am 196.168.1.13, do you like one of us?

The TCP code was written by Stephen Stair, and Stephen mentioned that the code isn't optimal and that he would do things differently todays, and yes, he mentioned that TCP is supposed to have many packets in the air, too. To some level, the code is working quite well, but I am not too familar with what it's doing exactly, and if there are any parts causing slowdowns.

Maybe there's some array size limiting the maximum number of TCP packets, or it's requesting only a certain amount of new packets per vblank. I have already tried to change some of those parameters, without success - but I guess I should try again, maybe it's working better in combination with the newer faster DMAs and with code executed in fast VRAM.

Stephen also suggested to drop TCP completely, and to use something like UDP instead. I am not sure if that would really help. I think he had mostly suggested it for reducing ARM9 cpu load, which might be a non-issue when clocking the ARM9 at 134MHz - which, I should make sure that I am really using that clock speed.


Top
 Profile  
 
PostPosted: Sun Jan 13, 2019 8:08 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4156
Location: A world gone mad
Several random things I'm going to state because I literally cannot figure out what this subject is even about. :-)

1. DHCP is a UDP-only protocol. TCP is not involved,

2. If you're having very slow DHCP negotiation:
2a. In my experience, it's not usually layer 0 or layer 1 (read: Ethernet vs. WiFi) issues, but rather DHCP client vs. server "quirks" that aren't immediately obvious or known to the user,
2b. Every DHCP server is different -- Busybox dhcpd vs. ISC dhcpd vs. Windows DHCP server vs. whatever else. They all behave differently. How to diagnose it requires packet captures being done on both the client *and* server for DHCP traffic (tcpdump/pcap filter: udp and (port 67 or port 68)), and start actually looking at where the delays happen. You might find that it happens only during a certain DHCP phase. For example: DHCPDISCOVER (client to broadcast) and DHCPOFFER (server to client) and DHCPREQUEST (client to server) happen very quickly, but the servers' final DHCPACK takes 4-5 full seconds. In this situation you need to examine the DHCPREQUEST payload to see what DHCP options are being sent to the server, and you need to enable DHCP debugging logs in the DHCP server to see what it might be doing,
3c. A common one I've seen a DHCP client including its requested hostname, and the DHCP server attempting to do DNS resolution of the hostname in question, where DNS is misconfigured on the actual AP (e.g. the long delay is caused by a DNS timeout),
3d. *Another* one I've seen is the client sending NetBIOS hostname information that the DHCP server tried to handle (pass through to a NetBIOS server which didn't exist; disabling that support entirely server-side worked great),
3e. **Another** one I've seen is DHCP clients using weird/wonky DHCP options that the server rejects, resulting in DHCPNAK and the client delaying, then sending another DHCPREQUEST with different options that work quickly (I talk about a different form of this beow),
3f. ***Another*** case I've seen is IP pool exhaustion, or "IP conflict". The latter is not "IP collision" -- I'm talking about where a DHCP client previously had an IP address of, say, 192.168.1.200, knowing this, and during its next subsequent DHCPREQUEST tells the DHCP server "I'd like IP address 192.168.1.200", but that address is allocated to another/different machine. The DHCP server responds with DHCPNAK, which causes the client to have to "forget" that it's 192.168.1.200 and resubmit the DHCPREQUEST without the DHCP option requesting said IP. If the DHCP client is "stupid" and hangs on to its previous IP excessively (e.g. lots of retries to DHCPNAK) due to a crummy DHCP implementation in the client, there would be delays,
3g. ****ANOTHER**** case I've seen are people running multiple DHCP servers on the same physical network. This is a big no-no, but this problem isn't specific to "just wireless". The problem is that of timing -- the client sends the initial DHCPDISCOVER to 0.0.0.0 UDP port 67, which with multiple DHCP servers on the same network would result in both servers seeing the request and responding to it with a DHCPOFFER. Which one the client sees _first_ is entirely chance (based on timing). While the MAC address of the DHCP server is certainly part of the layer 2 header, and all subsequent DHCP communication is done directly with the DHCP server the client saw "first", it's possible that the client might have to reissue DHCPDISCOVER at some point (you'd need to know how its DHCP client behaves; for example, standby/sleep mode might reissue DHCPDISCOVER if it has literally no idea what its IP address is); a good way to relieve the latter problem is to literally power the device off (and hope it doesn't save the previous client IP it was given in, say, NVRAM or something persistent),
3h. In short: the list just keeps growing. You *have* to do packet captures to see what DHCP options are being negotiated or rejected, and to figure out where the issue lies. You can rule out a specific client by using a different device (see: non-Nintendo product) and see if the slowness happens there too. If not, well then, you've isolated it to the device/client,

3. 802.11 speeds vary because:
3a. Signal strength is not directly proportional to speed, nor vice-versa,
3b. If your device has a maximum capability of 54mbps (802.11b/g @ 20MHz), there is literally no guarantee you are going to get it. On the other hand, if the client device can report active negotiated speed somehow, it's usually pretty accurate. But, like I said, even if the negotiated speed is, for example, 54mbit/s, it doesn't necessarily mean you're going to get that speed,
3c. One of the biggest and most annoying "features" of 802.11 and the underlying 802.11 ICs (or sometimes SoCs) is the fact that there are tremendous numbers of power-saving features that can completely destroy throughput. Many of them are not user-adjustable. To make matters worse, you can't necessarily work around these purely from the AP's perspective (e.g. disabling some feature); the 802.11 client and the AP can negotiate this, and sometimes it's the client that says "oh okay, I'll run at a slower speed". It all relates to Stupid Dumb Drivers(tm),
3d. WiFi congestion in general (I'm talking about 802.11 as a whole, and that includes 2.4GHz and 5GHz spectrums both, but 2.4GHz is the more problematic one) is not "purely WiFi". People often forget all the crap humans have that generate interference at 2.4GHz other than other APs -- NONE of which you will be able to see in, say, an AP scan (a spectrum analyser is the only way to know). Here's my short list: cordless phones, microwaves, baby monitors, wireless security cameras, garage door openers, Bluetooth, USB 3.0, and any other kind of little "wireless gadget" device that's on the cheap. 5GHz, which of course requires ICs/PHYs that support it, have less range but often **way** interference problems due to that they're less common. There's really no way to diagnose this problem without a spectrum analyser, which are expensive. There's been only one case (for me personally) where I've been able to rectify 2.4GHz interference problems at the AP level, and it required setting a very specific setting in the AP's wireless driver (binary blob/closed source Broadcom crap) to enable "interference mitigation" -- otherwise I'd be lucky to see 100kBytes/sec on a good day (with IM enabled, I would get roughly 15-20mbit/sec; comparatively, at 5GHz I'm able to pull literally hundreds of megabits per second reliably 100% of the time),
3e. Drivers. You might be surprised to find out some WiFi client devices rely heavily on CPU for some things you'd think had hardware offloading by now (all about cost savings). So sometimes throughput bottlenecks aren't caused by wireless itself but rather the CPU churning for extra processing by stuff that you'd think would be done in silicon,

4. Nintendo devices, in my experience, are notorious for being 802.11-annoying. That is to say, their 802.11 implementation is horrible, with bizarre stringent limitations imposed for no reason I can think of (probably chipset or drivers, but obviously there's no control over that). I've seen it on the DS, the DSi, and the 3DS. A common one I ran into with a 3DS was that I couldn't exclusively use 802.11n (which is compatible with b/g as a fallback if needed) (which would alleviate noise and other WiFi idiocies that are caused by b/g) -- this is a known limitation of the 3DS, surprisingly. I don't remember my DSi or 3DS ever getting very fast throughput (ever!) for updates, but that kind of throughput testing is totally separate/unrelated to DHCP. It sounds like (from your latest post) that you're using a custom OS with a home-grown TCP stack done by Some Dude On the Internet? *chuckles*

5. As far as calculating throughput in general across a wireless network -- no, it doesn't "get halved" like that (e.g. client 1 and client 2 are both attached to an AP at 54mbit/s PHY rates; it doesn't mean that the effective throughput when transferring data between client 1 and client 2 will be 27mbit/s). Technically, in a perfect environment (read: no frequency/spectrum interference), you'd be able to transfer at 54mbps. The only exception to this rule is if you're using WDS, which is a (very crappy/bad) protocol used for multiple AP meshing that halves the overall throughput due to the nature of the protocol. But in general, I've never seen a "clean" 802.11/b/g/n 20MHz wireless network reach 54mbps PHY speeds in practise -- it's more like 45mbit/sec in best-case scenarios. Common-use are probably 35-40mbit/sec.

6. Network throughput is always calculated in bits per second. Programs that display bytes per second are stupid; you lose granularity/accuracy using that unit. Storage (incl. memory/RAM/whatever) are in bytes. Any driver, application, etc. that you find only provides network throughput in bytes/sec (and there are many) has been designed by someone likely unfamiliar with this fact. I'm "accepting" of things that let you pick bits vs. bytes, but I encounter many that only show bytes, which is ridiculous.

7. If you're trying to do throughput testing with TCP, you should make sure that the router/gateway (not necessarily the same thing as the wireless AP!) supports TCP window scaling (RFC 1323), otherwise you're going to be limited to a TCP window size maximum of 64KBytes. Throughput testing, along with TCP stack analysis (all the way down to both the throughput testing programs' code on the client, *and* the TCP stack of the OS used on that client), is remarkably complicated. You really need someone who knows TCP at a very low level (read: an actual senior network engineer, often folks who are paid 6-digits for a dang good reason), along with packet captures for the TCP session in question done on *both ends* (server and client) -- one end is not EVER enough! Also, addendum: every time (I repeat: EVERY TIME) I've seen people dismiss TCP as "the reason for throughput problems" and say "use UDP" (often gamer-centric places), they've been proven repeatedly wrong in history -- TCP does not necessarily require ACK after *every single packet*. The TCP stack must support intelligent ACK (vs. an ACK for every packet), sometimes TCP PSH (TCP push) can help. Also, if there are retransmits needed, for quick recovery TCP SACK (selective ACK) per RFC 2018 must be implemented, otherwise all the packet associated with that sequence number have to be retransmit. There are cases where UDP (which can be lossy) is relevant, but this is certainly not that case -- I'd be willing to bet you hard cash of that.

Hope this helps in some way, or gives you an idea or things to try/look at.

Edit: added some bits about TCP stack features/behaviour to item 7.


Top
 Profile  
 
PostPosted: Mon Jan 14, 2019 11:30 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 941
Yes, the questions about DHCP delays and about TCP transfer speeds were separate questions.

DHCP
I didn't know that there are so many known things that could get wrong with DHCP. Some of them could be ruled out here: 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.
Above are the packets being sent/received by the DSi. I don't know what the router/access point are doing during the delays, perhaps they are sending something at 300MBit/s, or on wrong channels, or try to contact other servers for some reason.

Yeah, capturing DHCP packets would be a good idea, especially capturing those from another decice, like some android tablet, to see if it's having the same DHCP problems. I don't have any good capture tools unfortunately, I have an old laptop that might work for it, my other problem is lack of workspace (I would somehow have to balance the laptop on my elbow during captures).
If somebody wants to do some captures for DSi:
You could capture packets from DSi browser (which is suffering the same DHCP delays).
Or, capture packets from my wifiboot tool (here you could even "see" the delays: It's displaying DHCP DISCOVER and DHCP REQUEST (with noticeable delays after displaying that two strings, at least I am getting those delays in my network).

But in general: How fast is DHCP under normal circumstances? Could it be just a common thing to have those 700ms delays (or similar) on most or all routers?
Asking because it seems to be a general thing: My code has that issue, and the DSi browser, too. And I had that issue with both NDS-wifi, and DSi-wife hardware. And it occured with a fritzbox router in my old flat, and also with a zyxel router elsewhere.
If those delays are common, maybe most people won't even notice the delays because 700ms is just "almost" fast enough (and the delays might occur while booting up the OS, or while loading the browser).

TCP
Yes, the TCP code is homebrew, and Stephen was perhaps 13 years old when writing the dswifi library : ) but it's somehow working, and it's still used by everyone in nds/dsi scene, though maybe some are using it only for lower level hardware I/O, and something else for TCP and other higher level stuff (I think the nds-youtube-viewer is doing so; the dswifi library has some provisions for using only the low-level part of it).
Anyways, the transfer speed limitations might be totally unrelated from possible imperfections in the TCP code. I may have screwed up something myself, or I might have missed initializing some important wifi-hardware parameters. There are lots of configuration commands for bitrates, power saving, and priority streams, with tons of parameters. The problem isn't lack options, but rather too many options.
The DSi browser is leaving many options uninitialized, and sets others to some default values, hopefully it's using the right values there. And it's using this priority stream settings:
Code:
ath_create_pstream_cmd_1st:
@@begin:
 db 01h,01h // dw @@end-@@begin-6 // dw 0000h // dw WMI_CREATE_PSTREAM_CMD
 dd 14h         ;00h A_UINT32 4  minServiceInt      ;in msec (14h=20)
 dd 14h         ;04h A_UINT32 4  maxServiceInt      ;in msec (14h=20)
 dd 98967Fh     ;08h A_UINT32 4  inactivityInt      ;in msec (98967Fh=9999999)
 dd 0FFFFFFFFh  ;0Ch A_UINT32 4  suspensionInt      ;in msec (-1)
 dd 0           ;10h A_UINT32 4  serviceStartTime            (0)
 dd 14500h      ;14h A_UINT32 4  minDataRate        ;in bps  (14500h=83200)
 dd 14500h      ;18h A_UINT32 4  meanDataRate       ;in bps  (14500h=83200)
 dd 14500h      ;1Ch A_UINT32 4  peakDataRate       ;in bps  (14500h=83200)
 dd 0           ;20h A_UINT32 4  maxBurstSize                (0)
 dd 0           ;24h A_UINT32 4  delayBound                  (0)
 dd 5B8D80h     ;28h A_UINT32 4  minPhyRate         ;in bps  (5B8D80h=6000000)
 dd 2000h       ;2Ch A_UINT32 4  sba                         (2000h=8192)
 dd 0           ;30h A_UINT32 4  mediumTime                  (0)
 dw 80D0h       ;34h A_UINT16 2  nominalMSDU        ;in octects   ;uh, octeCts?
 dw 0D0h        ;36h A_UINT16 2  maxMSDU            ;in octects   ;uh, octeCts?
 db 00h         ;38h A_UINT8  1  trafficClass
 db 02h         ;39h A_UINT8  1  trafficDirection   ;DIR_TYPE (0=Uplink, 1=Downlink, 2=Bidir)
 db 0FFh        ;3Ah A_UINT8  1  rxQueueNum
 db 01h         ;3Bh A_UINT8  1  trafficType        ;TRAFFIC_TYPE (0=Aperiodic, 1=Periodic)
 db 00h         ;3Ch A_UINT8  1  voicePSCapability  ;VOICEPS_CAP_TYPE (0=Disable_for_this_ac, 1=Enable_for_this_ac, 2=Enable_for_all_ac)
 db 05h         ;3Dh A_UINT8  1  tsid
 db 00h         ;3Eh A_UINT8  1  userPriority       ;802.1D user priority
@@end:

Later on it's issuing two more priority stream commands (with trafficClass set to 01h and 03h, and most other parameters set to zero). I am using the same values as shown above in wifiboot, but I've no idea what the separate values are used for exactly, and if one of them is limiting the transfer speed to 600Kbytes/s. Hmmm, if "bps" means "bits/s", then "minPhyRate = 6000000 bps" might sound suspecible.

Nintendo Devices
The NDS-wifi hardware is very different than DSi/3DS-wifi hardware. And, until last week, there wasn't any homebrew code for DSi/3DS-wifi, and the official code from Nintendo is probably no good reference. For example, the DSi-shop software needs insane amounts of time to respond to user interactions - I am quite sure that's to blame on their shop software, not on the wifi hardware.
The DSi did originally use AR6002, which is also used by non-nintendo devices. I don't know how good or bad it is. Are there known issues for that hardware, like never remotely reaching 54Mbit/s?
The later DSi uses AR6013, and 3DS uses AR6014, those are most probably AR6003/AR6004 with two nintendo-specific customizations: built-in BB/RF hardware for NDS-wifi (which shouldn't disturb DSi/3DS-wifi), and a downgraded firmware for DSi/AR6002 compatibility (that might in fact remove access to some newer hardware features, like 5GHz, and maybe also disables 802.11n support).


Top
 Profile  
 
PostPosted: Mon Jan 14, 2019 1:16 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4156
Location: A world gone mad
Regarding DHCP...

Quote:
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.

Quote:
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:
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:
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


Quote:
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:
$ 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:
$ 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).


Top
 Profile  
 
PostPosted: Tue Jan 15, 2019 3:37 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 941
koitsu wrote:
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

Okay, that's quite fast. Good to know it can be that fast! So it looks as if I am doing something wrong for not getting the same speed (or my router is crap).
Can you log DHCP for NDS or DSi, too? Would be interesting if you get the same DHCP speed there. With DSi browser. Or with wifiboot (if you can run homebrew on NDS or DSi).

I've managed to get the laptop to capture the DSi's DHCP broadcasts with wireshark. Below is showing the DHCP Discover packet from DSi/wifiboot. Are there any obvious mistakes in that packet?

The basic problem is/was that the response to my DHCP packets appears about 700ms too late. But today I got it to behave even worse:
I've removed the DSi's AR6013 wifi-board, and replaced it by a AR6002 wifi-board, the result was not receive any DHCP responses at all ; /

Or, more confusingly it still worked with one WEP access point, but failed with another access point (no matter if using open/WEP/WPA/WPA2 on that access point). After lots of unsuccessful bug searching, I tried the connection test in DSi System Settings, and that failed, too, saying that it was unable to obtain an IP address. But, after clicking Try again, it passed okay - and thereafter my own wifiboot code started working with that access point, too. I can now connect to both APs, and get the same IP on both APs.

Now that it's working it's even harder to test what was wrong. I could try to pretend to have a different MAC address, maybe that causes the problem to reappear.

So far, I have no clue what had happened there. Hmmm, it seemed to start working once when the router figured out who I am, or where I am. Could it be that the router had memorized that I was originally using another access point - and still insisted on sending the DHCP reply to the old access point even though I was using another AP meanwhile?
If yes, there is a broadcast flag in the DHCP flags, that could be possibly used as workaround, but I don't think that it's really supposed to be used for that purpose.

It would be nice if DHCP would work without needing connection test in System Settings (and without the 700ms delay, which is still occurring).

Code:
No.     Time           Source                Destination           Protocol Length Info
      4 1.128749000    0.0.0.0               255.255.255.255       DHCP     342    DHCP Discover - Transaction ID 0xc2010000

Frame 4: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
    Interface id: 0
    WTAP_ENCAP: 1
    Arrival Time: Jan 15, 2019 20:05:59.977862000
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1547579159.977862000 seconds
    [Time delta from previous captured frame: 0.411978000 seconds]
    [Time delta from previous displayed frame: 0.411978000 seconds]
    [Time since reference or first frame: 1.128749000 seconds]
    Frame Number: 4
    Frame Length: 342 bytes (2736 bits)
    Capture Length: 342 bytes (2736 bits)
    [Frame is marked: True]
    [Frame is ignored: False]
    [Protocols in frame: eth:ip:udp:bootp]
    [Coloring Rule Name: UDP]
    [Coloring Rule String: udp]
Ethernet II, Src: Nintendo_xx:xx:xx (00:23:cc:xx:xx:xx), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
    Destination: Broadcast (ff:ff:ff:ff:ff:ff)
        Address: Broadcast (ff:ff:ff:ff:ff:ff)
        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
        .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
    Source: Nintendo_xx:xx:xx (00:23:cc:xx:xx:xx)
        Address: Nintendo_xx:xx:xx (00:23:cc:xx:xx:xx)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IP (0x0800)
Internet Protocol Version 4, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255 (255.255.255.255)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
    Total Length: 328
    Identification: 0x0100 (256)
    Flags: 0x00
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    Fragment offset: 0
    Time to live: 128
    Protocol: UDP (17)
    Header checksum: 0x38a6 [correct]
        [Good: True]
        [Bad: False]
    Source: 0.0.0.0 (0.0.0.0)
    Destination: 255.255.255.255 (255.255.255.255)
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: bootpc (68), Dst Port: bootps (67)
    Source port: bootpc (68)
    Destination port: bootps (67)
    Length: 308
    Checksum: 0xXXXX [validation disabled]   ;that was disabled here, but I have later checked, and it's correct checksum
        [Good Checksum: False]
        [Bad Checksum: False]
Bootstrap Protocol
    Message type: Boot Request (1)
    Hardware type: Ethernet
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0xc2010000
    Seconds elapsed: 0
    Bootp flags: 0x0000 (Unicast)
        0... .... .... .... = Broadcast flag: Unicast
        .000 0000 0000 0000 = Reserved flags: 0x0000
    Client IP address: 0.0.0.0 (0.0.0.0)
    Your (client) IP address: 0.0.0.0 (0.0.0.0)
    Next server IP address: 0.0.0.0 (0.0.0.0)
    Relay agent IP address: 0.0.0.0 (0.0.0.0)
    Client MAC address: Nintendo_xx:xx:xx (00:23:cc:xx:xx:xx)
    Client hardware address padding: 00000000000000000000
    Server host name not given
    Boot file name not given
    Magic cookie: DHCP
    Option: (53) DHCP Message Type
        Length: 1
        DHCP: Discover (1)
    Option: (61) Client identifier
        Length: 7
        Hardware type: Ethernet
        Client MAC address: Nintendo_xx:xx:xx (00:23:cc:xx:xx:xx)
    Option: (12) Host Name
        Length: 10
        Host Name: NintendoDS
    Option: (55) Parameter Request List
        Length: 3
        Parameter Request List Item: (1) Subnet Mask
        Parameter Request List Item: (3) Router
        Parameter Request List Item: (6) Domain Name Server
    Option: (60) Vendor class identifier
        Length: 8
        Vendor class identifier: sgIP 0.3
    Option: (255) End
        Option End: 255
    Padding


PS. Changing the priority stream parameters didn't affect the upload speed at all. I've tried to replace 6000000 by bigger and smaller and zero values, and completely removed the priority stream command, but it got faster or slower.


Top
 Profile  
 
PostPosted: Tue Jan 15, 2019 3:50 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 941
PPS. with the broadcast-request flag in DHCP flags, wireshark can also capture the responses. The seconds timetamps are:
Code:
1.947s  DHCP Discover (from DSi)
 (delay)
2.766s  DHCP Offer (from router)
2.769s  DHCP Request (from DSi)
 (delay)
3.482s  DHCP Ack (from router)

So the timings for outgoing data from DSi are looking fine - but the router fails to respond within reasonable time.


Top
 Profile  
 
PostPosted: Tue Jan 15, 2019 6:17 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4156
Location: A world gone mad
I don't see anything immediately obvious in the DISCOVER decoding, but I also wouldn't be able to do this kind of diagnosis reliably without physical access to both devices (DHCP client and DHCP server (router/AP)). I know literally nothing about your network configuration, router/AP setup, etc. thus cannot diagnose it. Doing this remotely is generally infeasible -- something that might take 10 minutes to figure out in person can take literally weeks online of back-and-forth.

Sadly, the data provided doesn't help narrowing down the situation. All it confirms is the same as what you said before: there's a 700-800ms delay from the client sends the DISCOVER to the time it receives an OFFER response, and the same 700-800ms delay from when the client sends the REQUEST to the time it receives an ACK.

What you need to really figure out is if the DISCOVER and REQUEST are received by the network layer on the router/AP sooner than 700-800ms (this is one reason why I always use routers that run some *IX derivative, so I can do packet captures with tcpdump). If they are, then this means the DHCP server on the router/AP itself is doing something stupid, thus taking 700-800ms to generate a response -- now you get to try and figure out why the DHCP server is doing that (another reason why I run *IX-based routers with open-source). If the DISCOVER/REQUEST aren't seen network-wise on the router/AP for 700-800ms, then the problem is elsewhere, very possibly within the 802.11 layer (see below).

That said... tell me something: how exactly did you manage to sniff encrypted (WEP/WPA/WPA2/whatever) DSi packets with a laptop running Wireshark? There's nothing special about UDP traffic going to 0.0.0.0 (broadcast address) -- that traffic is layer 4, while 802.11 frames (which are encrypted) sit somewhere between layer 1 and 2. ...or did you turn off encryption?

I do not have a DSi or NDS. The closest device I have is a Nintendo 3DS (not XL), and I don't know if it'll work with my 802.11 network at all given that I use WPA2+AES (I can't remember what the 3DS supports). I also cannot capture traffic from the 3DS itself; all I could provide is captures from the DHCP server. There is no chance in hell I will *ever* reconfigure my stuff use WEP -- that protocol is insecure and breakable within literally seconds. The dangers where I live of using WEP (doesn't matter if 64 or 128-bit) are literally tremendous given that I live in the centre of Silicon Valley.

If you want me to do DHCP server captures with my 3DS (say, loading up the store or something), I'd be glad to, assuming it works with WPA2+AES, but I suspect the result will be very fast/quick.

All that said: intermittent problems like what you're seeing ("it worked one moment and not the next") can sometimes be caused by spectrum interference. You can try picking a different channel on the AP (do not use "Auto", ever! Pick either channel 1, 6, or 11) and seeing if the problem goes away. It can also be caused by, sorry to say, cheap/crappy consumer routers. No I do not have an authoritative list, but a *lot* of them are generally really awful. This is one of the reasons why I ran the TomatoUSB firmware on my Asus router and contributed as a coder to the project, because I liked having some degree of insight into what the heck was going on. :-)

I remember running into absolutely *stupid* issues with my DS and DSi when it came to WEP/WPA compatibility. I'd get weird/vague errors from the Nintendo device if things weren't set up "just perfectly" on the router/AP 802.11-settings-wise. I knew others with the same problem, and their solution was to buy one of these and use it on a 32-bit Windows XP box. What's terrifying about that device is that it basically turns the Windows machine, via ICS, into a gateway/router of sorts. Be sure to read (not skim) the Criticism section on Wikipedia. I had similar (but different) complexities with my Wii. I concluded long ago Nintendo has literally no idea what they're doing when it comes to IP networking or the Internet in general.


Top
 Profile  
 
PostPosted: Wed Jan 16, 2019 6:18 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 941
No, I didn't tweak wireshark into low-level capturing of encrypted packets from other network members. I just got the packets because Discover+Request are literally broadcast to all network members (and after setting the request-broadcast-response flag in the outgoing dhcp "flags" field, I also got the Offer+Ack responses as visible broadcasts). The capture timestamps do at least confirm that my packets have entered the network, and that the response is late (ie. they aren't stuck in DSi's tx/rx queues).

Today I have also captured Discover+Request from an android tablet connecting to different access points (thanks for that idea!), and the android's Discover+Request are 800-1000ms apart, too. So those delays seem to be a general bug in the router/network, not a bug in my DSi wifiboot source code.

Yes, both 3DS and DSi can do 2.4GHz with WPA2-AES-PSK. But a capture from 3DS won't help too much for comparing it against DHCP delays spotted on NDS and DSi, and as it looks now, those delays aren't my fault anyways, so I won't need to spend more time on bugfixing the problem. But, if somebody does have a NDS or DSi, it would be nice to hear if wifiboot's DHCP stage works free of delays in your network.

I don't think that there's much interference here, I am currently stranded in a remote corner of the city, close to a forest, and not too densely populated, with many older people whom probably don't use much internet/streaming at all (and I doubt that they are running microwave ovens all night long). At worst, having heard of strangers wanting to steal their aerial TVs, yes, they might switch on security cams at night ; )

For the missing DHCP reply, my network looks somewhat as so:
Router <-----> Switch <-----> AP1 <-----> AP2
Using AP2 was working okay, but using AP1 failed because of missing DHCP reply (although the preceeding EAPOL 4-way handshake worked with it). Maybe the Router or AP1 still thought that I were connected to AP2 at that time (I didn't send any disconnect messages) (though after connecting to AP1, it would be a bit illogical if AP1 would still treat me as being connected to AP2). But yeah, I would need better capture tools & find a way to reproduce the issue for tracking down the problem and finding a workaround.


Top
 Profile  
 
PostPosted: Sun Jan 20, 2019 3:35 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 941
koitsu wrote:
5. As far as calculating throughput in general across a wireless network -- no, it doesn't "get halved" like that (e.g. client 1 and client 2 are both attached to an AP at 54mbit/s PHY rates; it doesn't mean that the effective throughput when transferring data between client 1 and client 2 will be 27mbit/s). Technically, in a perfect environment (read: no frequency/spectrum interference), you'd be able to transfer at 54mbps.

I've thought about that for a while, and I could see it working theoretically, but only if the clients are directly connected to each other (without going through the access point). And doing that would bring up some problems:

First would be distance, if the clients are too far apart from each other, but have the access point located in the middle, then they would need the access point, so that would require signal detection, ideally with switching between using and not using the AP as needed.

Second would be wpa/wpa2 encryption keys, each client has a different pairwise key for client-to-AP communication, so those different keys won't match for client-to-client. Using the group key would work for client-to-client, but that key is supposed for broadcasts, not so much for "private" data traffic. There's is something called "STAkey" in the IEEE specs, but I haven't figured out what it's good for exactly, it seems to be supposed for client-to-client stuff. But I think there are only 4 keyslots for wep/wpa/wpa2. Slot 0 is pairwise key, slot 1/2 are group key(s), that would leave slot 3 unused, so I assume the "STAkey" might use that slot (?) but even then, that would allow only two clients, if there's a third client then one of them would need to go through the access point (preferably the one with least traffic).

Third would be clients on different APs. If they are on different channels then they won't disturb each other (so no need for direct client-to-client). If they are on the same channel then they could communicate directly, but only if they agree on using a specific password/key (that would require using something like RSA, but I haven't spotted any such thing in the IEEE doc).

My own software is definetely to crappy to solve any of that problems : )
And more professional software... does that have solved that issues?


Top
 Profile  
 
PostPosted: Sun Jan 20, 2019 4:40 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4156
Location: A world gone mad
nocash wrote:
koitsu wrote:
5. As far as calculating throughput in general across a wireless network -- no, it doesn't "get halved" like that (e.g. client 1 and client 2 are both attached to an AP at 54mbit/s PHY rates; it doesn't mean that the effective throughput when transferring data between client 1 and client 2 will be 27mbit/s). Technically, in a perfect environment (read: no frequency/spectrum interference), you'd be able to transfer at 54mbps.

I've thought about that for a while, and I could see it working theoretically, but only if the clients are directly connected to each other (without going through the access point).

Okay, so I did some reading on this. Foremost, 802.11 isn't a protocol I'm particularly "knowledgeable" about (when compared to, say, Ethernet or other bits). It's one of those protocols that's constantly being screwed with every year and nearly impossible for me to keep track of. Plus, I don't have high-end protocol analysers to really get familiar with it all (while Ethernet is pretty well-known at this point).

Anyway, yes, I'm incorrect in this case -- the bandwidth effectively does get halved. There's two reasons for this: 1) 802.11, in 99% of cases out there, is a half-duplex protocol: a client cannot send and receive simultaneously, and 2) two clients share the same frequency/channel to the AP, which means they're both utilising the same frequency simultaneously, effectively halving things.

It gets confusing when you introduce stuff like MIMO and other god-knows-whats into the picture, all newer-ish stuff I don't fully understand for reasons said above.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 14 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 7 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group