I took a good VLAN packet and a bad non-VLAN packet and put then into
Wireshark. The IP header checksums are both correct. Plus the rest of
the packet looks to be in acceptable form. Only the TCP checksums are
wrong.
Maybe when the VLAN hardware gets turned off there is a bug in the
code that is
Try disabling transmission offloading and do a tcpdump again.
ethtool -K eth0 tx off
On Mon, Sep 23, 2013 at 8:11 PM, jonsm...@gmail.com wrote:
> I pasted that twice by accident
>
> root@OpenWrt:/# ethtool --show-offload eth0
> Features for eth0:
> rx-checksumming: on [fixed]
> tx-checksu
On Mon, Sep 23, 2013 at 2:27 PM, Diego Lopez Recas wrote:
> Try disabling transmission offloading and do a tcpdump again.
>
> ethtool -K eth0 tx off
root@OpenWrt:/# ethtool -K eth0 tx off
Cannot change tx-checksumming
Could not change any device features
root@OpenWrt:/#
>
>
>
> On Mon, Sep 23,
I don't know, do you see bad checksums with wireshark or tcpdump on your
desktop? If the NIC does the final checksum computing, this error might
just mean that tcpdump is not capturing the final value of this header
field.
On Mon, Sep 23, 2013 at 8:37 PM, jonsm...@gmail.com wrote:
> Somehow this
Somehow this failure is intertwined with the VLAN code since
everything works once I turn VLANs on.
--
Jon Smirl
jonsm...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt
Turn on the VLAN and all the errors go away...
root@OpenWrt:/etc/config# tcpdump -n -v -x -e -i eth0
tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size
65535 bytes
02:28:09.258040 70:71:bc:b8:9b:ee > 00:0a:52:00:00:02, ethertype
8
Yes, I meant you checked it on the rt5350.
On Mon, Sep 23, 2013 at 7:38 PM, jonsm...@gmail.com wrote:
> On Mon, Sep 23, 2013 at 1:34 PM, Diego Lopez Recas
> wrote:
> > That is interesting. Can you check whether you are using hardware
> checksum
> > offloading?
> >
> > Install 'ethtool' and run:
I pasted that twice by accident
root@OpenWrt:/# ethtool --show-offload eth0
Features for eth0:
rx-checksumming: on [fixed]
tx-checksumming: on
tx-checksum-ipv4: on [fixed]
tx-checksum-ip-generic: off [fixed]
tx-checksum-ipv6: off [fixed]
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: off
Run on the rt5350
root@OpenWrt:/# ethtool --show-offload eth0
Features for eth0:
rx-checksumming: on [fixed]
tx-checksumming: on
tx-checksum-ipv4: on [fixed]
tx-checksum-ip-generic: off [fixed]
tx-checksum-ipv6: off [fixed]
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: off [fixed]
scatt
That is interesting. Can you check whether you are using hardware checksum
offloading?
Install 'ethtool' and run:
ethtool --show-offload eth0
On Mon, Sep 23, 2013 at 5:37 PM, jonsm...@gmail.com wrote:
> I used
> tcpdump -n -v -e -i eth0
>
> So what is causing those incorrect checksums?
>
>
On Mon, Sep 23, 2013 at 1:34 PM, Diego Lopez Recas wrote:
> That is interesting. Can you check whether you are using hardware checksum
> offloading?
>
> Install 'ethtool' and run:
>
> ethtool --show-offload eth0
My desktop has tcp offload but those tcpdumps were done on the rt5350.
>
>
> On Mo
I used
tcpdump -n -v -e -i eth0
So what is causing those incorrect checksums?
192.168.1.40 > 224.0.0.22: igmp v3 report, 3 group record(s)
[gaddr 224.0.0.251 is_ex { }] [gaddr 239.192.83.80 is_ex { }] [gaddr
239.255.255.250 is_ex { }]
02:35:41.227580 00:1f:90:7e:af:3d > 01:80:c2:00:00:00, 80
Try using:
tcpdump -n -e -i eth0 tcp port 80
You'll see ethernet headers including vlan tags.
On Sat, Sep 21, 2013 at 1:54 AM, jonsm...@gmail.com wrote:
> tcpdump of tcp sessions failing to open
> 192.168.1.85 openwrt
> 192.168.1.40 desktop
>
> root@OpenWrt:/# tcpdump
> tcpdump: WARNING: eth0
tcpdump of tcp sessions failing to open
192.168.1.85 openwrt
192.168.1.40 desktop
root@OpenWrt:/# tcpdump
tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 b
ps on working system with vlan enabled.
root@OpenWrt:/# ps
PID USER VSZ STAT COMMAND
1 root 1368 S/sbin/procd
2 root 0 SW [kthreadd]
3 root 0 SW [ksoftirqd/0]
4 root 0 SW [kworker/0:0]
5 root 0 SW< [kworker/0:0H]
6 roo
I don't think that makes any sense. TCP doesn't care about anything in the
ethernet header and its implementation is platform independent. The problem
must be elsewhere. Can you post the contents of all your config files and
the output of 'ps' command?
BTW, I'm not positive about this, but you mig
On Fri, Sep 20, 2013 at 9:36 AM, Diego Lopez Recas wrote:
> I don't see how the problem is with the switch if you can ping to the
> device. To my understanding, the switch is unaware of the protocol above
> link layer and arp.
The RT5350 can send packets fine when it is messed up, it just can't
r
I don't see how the problem is with the switch if you can ping to the
device. To my understanding, the switch is unaware of the protocol above
link layer and arp.
On Fri, Sep 20, 2013 at 2:48 PM, jonsm...@gmail.com wrote:
> Seems to me like the vlan=0 case is broken on the RT5350.
>
> So for tes
Seems to me like the vlan=0 case is broken on the RT5350.
So for testing...
First I removed everything from file/etc... and rebuild
This configuration got generated, I edited it to change the IP.
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
optio
I don't have this problem. My switch seems to work normally. This is my
configuration:
config interface loopback
option ifname lo
option proto static
option ipaddr 127.0.0.1
option netmask 255.0.0.0
config interface lan
option ifname eth0
option type bridge
option proto static
option ipaddr 1
On Thu, Sep 19, 2013 at 12:42 PM, Diego Lopez Recas wrote:
> Hi Jon,
>
> I don't know what you mean with "default 'off' state", but I'm using an
> RT3052F SoC and I have to explicitly specify the the pvid for the port in
> vlan 2 to make it work properly. I think this is usual. From
> http://wiki.
For example do a clean openwrt build with nothing in /files/etc. It
will generate a network file with the VLAN support turned off. RT5350
is not functioning with VLAN turned off. If used to work that way
about six months ago.
config switch
option name 'rt305x'
option reset '1'
option enable_v
On Thu, Sep 19, 2013 at 2:43 PM, jonsm...@gmail.com wrote:
> On Thu, Sep 19, 2013 at 2:41 PM, jonsm...@gmail.com
> wrote:
>> For example do a clean openwrt build with nothing in /files/etc. It
>> will generate a network file with the VLAN support turned off. RT5350
>> is not functioning with VL
On Thu, Sep 19, 2013 at 2:41 PM, jonsm...@gmail.com wrote:
> For example do a clean openwrt build with nothing in /files/etc. It
> will generate a network file with the VLAN support turned off. RT5350
> is not functioning with VLAN turned off. If used to work that way
> about six months ago.
>
>
Hi Jon,
I don't know what you mean with "default 'off' state", but I'm using an
RT3052F SoC and I have to explicitly specify the the pvid for the port in
vlan 2 to make it work properly. I think this is usual. From
http://wiki.openwrt.org/doc/uci/network/switch :
"Tagged packets received on a por
Has anyone tried using the Ethernet switch on Ralink lately? I don't
believe it is working correctly in the default 'off' state. The
failure is that the Ralink CPU can't receive any packets from Ethernet
(or those packet are corrupted by the VLAN tag).
If I enable the switch it works properly. I'
26 matches
Mail list logo
