Socket problems...
ernstoud
Outgoing traffic is really good, fast and reliable it seems. Large
downloads are fine and as fast as wireless goes.
But any inbound telnet session aborts when I try do do an "ls /bin"
for instance.
Logging in goes fine but when I do an "ls /bin" or an "ls /usr" the
session aborts. The weird thing is that a "ls /var" is fine. But the
moment I do an "ls /bin", it aborts.
I think it has to do with the amount of text an ls command
generates...
I tried telnetting in from windows, linux etc.; several telnet
clients.. all the same result.
Very, very weird.
Instead I installed OpenSSH and used it's debug mode and that shows
that just when I session should start the daemon has socket read
problems... timeouts.
So I thought that unix socket support has not been configured in, but
it is.
Anyone got a clue? A wireless system is fine but ofcourse I need to be
able to log in to it...
TIA
Ernst
ernstoud
then I can log in using telnet and ssh. So it is a wireless related
issue, not hardware because it happens with both my zydas wlan usb
sticks (one from icidu and one from msi).
Ernst
Rumen Telbizov
Although you say that large downloads are fine I was wondering if
might be having MTU issues.
I had this problem with my bifferboard and Asus usb wifi dongle. It turned
out that its maximum packet size is less than 512 bytes. I am not sure if
it's a restriction of the wifi dongle or the usb.
Anyway why don't you try to limit the MTU to 400, just for the kicks?
In my debian the configuration looks like?
pre-up /sbin/ifconfig $IFACE
Cheers,
Rumen Telbizov
--
You received this because you are subscribed to the "Bifferboard" Google group - honest!
To unsubscribe from this group, send email to bifferboard...@googlegroups.com
Rumen Telbizov
So if you're using DHCP as I do you need something like:
pre-up /sbin/ifconfig $IFACE mtu 400
otherwise with static config it should be simply:
mtu 400
ernstoud
(I remember that ifconfig said MTU is set at 1500 currently).
Will let you know.
Ernst
On Feb 7, 12:14 am, Rumen Telbizov <telbi...@gmail.com> wrote:
> This got truncated ...
>
> So if you're using DHCP as I do you need something like:
> pre-up /sbin/ifconfig $IFACE mtu 400
>
> otherwise with static config it should be simply:
> mtu 400
>
> On Sat, Feb 6, 2010 at 3:13 PM, Rumen Telbizov <telbi...@gmail.com> wrote:
> > Hello,
>
> > Although you say that large downloads are fine I was wondering if
> > might be having MTU issues.
> > I had this problem with my bifferboard and Asus usb wifi dongle. It turned
> > out that its maximum packet size is less than 512 bytes. I am not sure if
> > it's a restriction of the wifi dongle or the usb.
>
> > Anyway why don't you try to limit the MTU to 400, just for the kicks?
> > In my debian the configuration looks like?
> > pre-up /sbin/ifconfig $IFACE
>
> > Cheers,
> > Rumen Telbizov
>
> >> bifferboard...@googlegroups.com<bifferboard%2Bunsu...@googlegroups.com>
ernstoud
Thank you very much for your tip. This indeed was the problem, with
MTU 400 I can telnet in properly, any command works fine and even
OpenSSH works fine..
This is the benefit of a forum like this; helpful advice which
otherwise would have taken ages to get.
Thanks again!
Ernst
On Feb 7, 12:14 am, Rumen Telbizov <telbi...@gmail.com> wrote:
> This got truncated ...
>
> So if you're using DHCP as I do you need something like:
> pre-up /sbin/ifconfig $IFACE mtu 400
>
> otherwise with static config it should be simply:
> mtu 400
>
> On Sat, Feb 6, 2010 at 3:13 PM, Rumen Telbizov <telbi...@gmail.com> wrote:
> > Hello,
>
> > Although you say that large downloads are fine I was wondering if
> > might be having MTU issues.
> > I had this problem with my bifferboard and Asus usb wifi dongle. It turned
> > out that its maximum packet size is less than 512 bytes. I am not sure if
> > it's a restriction of the wifi dongle or the usb.
>
> > Anyway why don't you try to limit the MTU to 400, just for the kicks?
> > In my debian the configuration looks like?
> > pre-up /sbin/ifconfig $IFACE
>
> > Cheers,
> > Rumen Telbizov
>
> >> bifferboard...@googlegroups.com<bifferboard%2Bunsu...@googlegroups.com>
Rumen Telbizov
You're welcome. I'm glad it worked.
You might want to try experimenting with different MTU sizes by
sending ping with different packet sizes and taking the largest one that
makes it through.
I am still not sure what is reducing the packet size to this much. My only
suspicion is the usb bus. lsusb shows me a 512 bytes packet size for this
device. I am not quite certain that this is the reason since I didn't have
much time investigating this. Let me know if you find what the reason is.
Cheers,
Rumen Telbizov
ernstoud
448 (in rc.local) and it is running fine and fast enough. The weird
thing is that at 1500 it runs fine on my notebook using slackware, so
it could be something in the slackware config for the bifferboard or
something in the RDC southbridge controlling the USB ports.
In the zd1211 coding there is a remark somewhere that USB transfers
are limited to 4096 bytes so if this is true it can't be the reason.
Considering it working on my notebook on the same OS, my bet would be
some USB implementation quirk on RDC's side...
I also noticed that on my notebook it connects at USB 2.0 (fast)
speeds and at the bifferboard at high speed (USB 1.1) so there are
differences.
Since WLAN 802.11g maxes out at around 6 Mbyte/sec anyway I don't
think a lower MTU is a problem whatsoever...
... but I am glad that you had the same problem and responded to my
post. I don't believe I could have found this otherwise. I always read
that sub-optimal MTU settings cause lower throughput because of
fragmented packets but have never heard that aborted sessions could
occur.
It also weird that using the WLAN connection when still set at MTU
1500 caused no problems whatsoever downloading slackware packages
using wget but that telnet/ssh inwards went awry.
Perhaps the http/ftp protocols are better in this aspect than telnet/
ssh.
Thanks again.
Ernst
On Feb 7, 8:17 pm, Rumen Telbizov <telbi...@gmail.com> wrote:
> Hey man,
>
> You're welcome. I'm glad it worked.
> You might want to try experimenting with different MTU sizes by
> sending ping with different packet sizes and taking the largest one that
> makes it through.
>
> I am still not sure what is reducing the packet size to this much. My only
> suspicion is the usb bus. lsusb shows me a 512 bytes packet size for this
> device. I am not quite certain that this is the reason since I didn't have
> much time investigating this. Let me know if you find what the reason is.
>
> Cheers,
> Rumen Telbizov
>
> > <bifferboard%2Bunsu...@googlegroups.com<bifferboard%252Buns...@googlegroups.com>
Rumen Telbizov
The HTTP/FTP protocols themselves have no mechanism to control the
maximum packet size since they don't really know the underlying layers.
Moreover they are application streaming protocols and don't control the size of the
packets they send (they have no guarantee that 1 write() into a socket
will result into 1 TCP segment being sent, the kernel buffers data).
TCP does have a path MTU discovery mechanism which might work but
might not. It also supports a flow control mechanism (sliding window) and is able to negotiate sizes
of the maximum segment that it supports (by advertising lower windows sizes). It usually takes
into account the underlying interfaces' MTU that the connection is established upon (the USB wifi dongle in your case).
I was really surprised to hear that HTTP downloads went fine since HTTP
downloads usually fill in big chunks of data and therefore the network segment
is filled up easily since a lot of data is transferred fast. SSH on the other hand sends
very little in one packet (usually just one keystroke) since the Nagle algorithm
is usually disabled on those sockets (TCP_NODELAY).
Now while this is usually true for the commands being sent to the server it is not for responses
coming back from the server (like huge ls listings for example) or during the initial
handshake where a lot of data is transferred in bug chunks.
This is where my ssh used to hang. I was able to see the beginning of the ssl/ssh
handshake and out of a sudden a stall.
How you managed to establish a full ssh connection is still a mystery to me :)
I don't think that 448 bytes MTU size will be such a big issue for an application
running on BB. Yes there will be more packets, more headers and more overhead
but my tests show pretty decent download speeds. Unless you're hosting your
torrents of of your BB then I think you'll be fine :)
Cheers,
Rumen Telbizov
ernstoud
I measured that the download speed is halved.
In the code of the zd1211rw driver there is a line saying:
---
if (interface_to_usbdev(usb->intf)->speed == USB_SPEED_HIGH) {
rx->usb_packet_size = 512;
---
While the USB spec says "The data field may range from zero to 1,024
bytes and must be an integral number of bytes."
Perhaps this explains why an MTU around 500 bytes kills usb-wireless
connections. But shouldn't the network layer or the driver or the
network layer automatically cater for fragmenting larger TCP/IP
packets into the smaller USB packets... why would a larger MTU create
problems... and why is no-one else having this problem? I googled and
found nothing on this searching for usb and wireless. Weird.
Tomi Hautakoski
Hi,
> I am trying to get to the bottom of this (sort of) since with MTU 448
> I measured that the download speed is halved.
>
> if (interface_to_usbdev(usb->intf)->speed == USB_SPEED_HIGH) {
> rx->usb_packet_size = 512;
> problems... and why is no-one else having this problem? I googled and
I can confirm that I have seen this same problem when using zd1211rw
driver (A-link WL54USB). Unfortunately, there hasn't been time to really
dig into this yet...
++Tomi
ernstoud
This is some weird zd1211rw driver problem.
I compiled a new kernel with both zd1211rw and prism modules and used
a Thomson st121g usb wlan stick (prism chipset).
That prism based stick works fine with an MTU of 1500. If I take it
out and insert the zd1211b based stick it only works with an MTU <
500. So this is a weird bug. Perhaps some combination of driver/
hardware/kernel/mac80211 but hard to investigate further. If I feel
like it I will try and build a kernel with loads of debug configs
set... and see whether that gives a clue.
ernstoud
- I found that in the vendor driver for the zd1211b (which I cannot
get to compile on 2.6.32) there is one place in the source where a
special extra compile flag is used called RDC_R8610_FRAG_FIX. When
enabled it performs a couple of extra statements. These statements and
the name of this compile flag really makes me think that Zydas
experienced the same problems when running on the RDC platform and
found a fix. This fix is nowhere in the community zd1211rw driver. The
coding is so different and badly commented in both sources that coding
this fix also in the community driver is hopeless...
- I found an RT2500usb based asus usb wlan stick WL-167g, works on the
bifferboard but transfer speeds are one-tenth of what it should be.
Either it is broken or this driver has a bug also. But since its
signal strength is rather bad even one meter away from the AP I guess
there is something broken with this (new) stick. I have another one on
its way; either rt2500 or rt73 based.
Ernst
On Feb 14, 8:11 pm, ernstoud <ernst...@gmail.com> wrote:
> @Tomi; Good to know I am not alone.
>
> This is some weird zd1211rw driver problem.
>
> I compiled a new kernel with both zd1211rw and prism modules and used
> a Thomson st121g usb wlan stick (prism chipset).
>
> That prism based stick works fine with anMTUof 1500. If I take it
ernstoud
1.
When the bifferboard is connected via a ZD1211b stick to my wlan and I
use the serial console on the bifferboard I can have the bifferboard
download files with an MTU of 1500 at around the speed to be expected
in my wlan (600 kbps).
2.
When I connect my notebook to my wlan and use a telnet or ssh session
on it to connect to the same bifferboard as above without any change I
have to set MTU on the bifferboard to around 448 and as a result
download session speeds are halved.
It is beyond me why in the first scenario an MTU of 1500 works fine
and in the second scenario when using an MTU of 1500 sessions get
aborted and an MTU of 448 is required for stable behaviour.
This behaviour is due to the ZD1211b or its driver. If have now tried
RT2571F (Asus WL-167g), RT2780 (Asus Wl-160n) and Intersil Prism54
(SpeedTouch ST121g) based sticks that do not exhibit this behaviour at
all.
Andrew Scheller
> and in the second scenario when using an MTU of 1500 sessions get
> aborted and an MTU of 448 is required for stable behaviour.
A complete stab in the dark, but maybe in the first scenario only the
incoming packets are 'big', but in the second scenario both incoming
and outgoing packets are 'big'? I guess you could try repeating the
first scenario, but uploading a file instead of downloading a file?
*shrug*
Lurch
ernstoud
internet to the bifferboard so I don't see the difference...
Also it is not the download that is the problem but the aborted telnet
or ssh sessions to the notebook. The slower download is a consequence
of the lower MTU.
Somehow when the ZD1211b needs to deal with an outside originated
session (inward telnet or ssh) it runs into a problem; a session
originated from the bifferboard goes fine at any MTU.
E.