If TCP really isn't replying, then you might be able to find out why
by watching the counters that "netstat -s" prints. Perhaps there is
something invalid about the packets from the TCP stack's point of
view, or something odd about routes from the IP stack's point of view,
or maybe the checksum ad
ives error “protocol family not supported”
>
> ** **
>
> Regards,
>
> Sheili
>
> ** **
>
> *From:* discuss-boun...@openvswitch.org [mailto:
> discuss-boun...@openvswitch.org] *On Behalf Of *Aaron Rosen
> *Sent:* 11 January 2012 07:30
> *To:* Ben
this gives error "protocol family not supported"
Regards,
Sheili
From: discuss-boun...@openvswitch.org
[mailto:discuss-boun...@openvswitch.org] On Behalf Of Aaron Rosen
Sent: 11 January 2012 07:30
To: Ben Pfaff
Cc: discuss@openvswitch.org
Subject: Re: [ovs-discuss] not seeing
Hey Ben,
Sorry for some reason this packet seem to be showing up now.. I'm not quite
sure what the deal was before :/
1f:29:32:92:4d (oui Unknown) > 00:1b:21:6a:85:88 (oui Unknown), ethertype
IPv4 (0x0800), length 74: 10.0.0.10.36985 > 10.0.0.13.5004: S
00:1f:29:32:92:4d (oui Unknown) > 00:1f:2
As an experiment, you could start to add "printk"s to the kernel
module. That's what I'd do next while debugging the problem.
On Tue, Jan 10, 2012 at 05:10:38PM -0500, Aaron Rosen wrote:
> I'm not sure if this helps eliminate anything but I just tried this in
> mininet and the same thing occurs
I'm not sure if this helps eliminate anything but I just tried this in
mininet and the same thing occurs there if dl_src/nw_src ==
dl_dst/nw_dst .
Thanks,
Aaron
#packet that goes in
14:02:47.309736 06:3b:31:b8:d5:a2 (oui Unknown) > ca:05:25:be:fd:70
(oui Unknown), ethertype IPv4 (0x0800), len
Here are lines (154-158) from here http://codepad.org/APdmOTGN (more debug)
Thanks,
Aaron
Jan 10 14:46:07 localhost ovs-vswitchd: 04385|dpif|DBG|system@dp0: miss
upcall:
Jan 10 14:46:07 localhost ovs-vswitchd:
in_port(0),eth(src=00:1f:29:32:92:4d,dst=00:1b:21:6a:85:88),eth_type(0x0800),ipv4(src=
I'd expect such packets to show up in tcpdump in any case.
On Tue, Jan 10, 2012 at 01:35:48PM -0500, Aaron Rosen wrote:
> I'd be curious what the expected behavior should be if linux sees a packet
> arriving on an interface matching it's dl_src/src_ip. (Since this should
> have probably gone throu
If you apply the following series:
http://openvswitch.org/pipermail/dev/2011-December/013943.html
http://openvswitch.org/pipermail/dev/2011-December/013944.html
http://openvswitch.org/pipermail/dev/2011-December/013945.html
and then turn up the log level for the "dpif" module, then we should
be abl
I'd be curious what the expected behavior should be if linux sees a packet
arriving on an interface matching it's dl_src/src_ip. (Since this should
have probably gone through lo ).
I also enabled log_martians and it's not saying anything about this.
Thanks,
Aaron
On Tue, Jan 10, 2012 at 1:32 PM
These packets are the normal SYN packets to initial a TCP connection.
The weird thing though is if I use this flow_mod it works fine: (using a
fake ip/mac as the response).
cookie=0x0, duration=6.622s, table=0, n_packets=93776, n_bytes=6191149,
idle_timeout=100,priority=65535,tcp,in_port=65534,
The datapath actions look like what I'd expect to see. I'd expect the
modified packets to show up in tcpdump. I see that there are only two
such packets over an 18-second period. Can you send them faster? It
looks like the second packet didn't get caught by the kernel flow
("used:never") so bot
pg46 openvswitch # ovs-ofctl dump-flows dp0
NXST_FLOW reply (xid=0x4):
# Removed other flows here for paste...
cookie=0x0, duration=18.467s, table=0, n_packets=2, n_bytes=148,
idle_timeout=100,priority=65535,tcp,in_port=65534,vlan_tci=0x,dl_src=00:1f:29:32:92:4d,dl_dst=00:1b:21:6a:85:88,nw_src
On Tue, Jan 10, 2012 at 12:15:39PM -0500, Aaron Rosen wrote:
> Hello,
>
> I have a quick question about what could be happening to these packets.
>
> I start a tcp connection 10.0.0.10 > 10.0.0.13:
>
> 12:02:55.961344 00:1f:29:32:92:4d (oui Unknown) > 00:1b:21:6a:85:88
> (oui Unknown), ethertype
Hello,
I have a quick question about what could be happening to these packets.
I start a tcp connection 10.0.0.10 > 10.0.0.13:
12:02:55.961344 00:1f:29:32:92:4d (oui Unknown) > 00:1b:21:6a:85:88
(oui Unknown), ethertype IPv4 (0x0800), length 74: 10.0.0.10.50490 >
10.0.0.13.5004: S
Then the foll
15 matches
Mail list logo
