ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

I'm not used to seeing this error in the logs:

 Discarding packet based on xid: 17313 != 52692
 validate_common returned False
 Discarding packet based on xid: 17313 != 52692
 validate_common returned False

I looks like your DHCP server isn't sending DHCP responses with the proper XID. The relevant error message is coming from line 260 of multi_interface_roam/src/multi_interface_roam/dhcp.py

You'll probably want to get in touch with your network administrator so see if they have any insight into this.

I'm not used to seeing this error in the logs:

 Discarding packet based on xid: 17313 != 52692
 validate_common returned False
 Discarding packet based on xid: 17313 != 52692
 validate_common returned False

I It looks like your DHCP server isn't sending DHCP responses with the proper XID. The relevant error message is coming from line 260 of multi_interface_roam/src/multi_interface_roam/dhcp.py

You'll probably want to get in touch with your network administrator so see if they have any insight into this.

I'm not used to seeing this error in the logs:

 Discarding packet based on xid: 17313 != 52692
 validate_common returned False
 Discarding packet based on xid: 17313 != 52692
 validate_common returned False

It looks like your DHCP server isn't sending DHCP responses with the proper XID. The relevant error message is coming from line 260 of multi_interface_roam/src/multi_interface_roam/dhcp.py

You'll probably want to get in touch with your network administrator so see if they have any insight into this.

EDIT1:

I would do a packet dump on wan0 and try to trace the DHCP negotiation that's going on, to see if it's getting corrupt or out of sync somehow; paying particular attention to the XID field in the DHCP packets. Something like the following tcpdump command should be a start:

sudo tcpdump -i wan0 -s 1500 -vvv port bootps or port bootpc

If multi_interface_roam is taking the interface up and down, that may disrupt tcpdump. In that case, you'll have to play with the interface parameter. Maybe try -i any or look into the packet tap interface options.

It may also be worth doing the same packet dump on your DHCP server, and possibly the DHCP relay if you have one in your network, to see if they're processing DHCP requests properly. It's probably also worth looking at the DHCP logs if you can get to them.

I'm not used to seeing this error in the logs:

 Discarding packet based on xid: 17313 != 52692
 validate_common returned False
 Discarding packet based on xid: 17313 != 52692
 validate_common returned False

It looks like your DHCP server isn't sending DHCP responses with the proper XID. The relevant error message is coming from line 260 of multi_interface_roam/src/multi_interface_roam/dhcp.py

You'll probably want to get in touch with your network administrator so see if they have any insight into this.

EDIT1:

I would do a packet dump on wan0 and try to trace the DHCP negotiation that's going on, to see if it's getting corrupt or out of sync somehow; paying particular attention to the XID field in the DHCP packets. Something like the following tcpdump command should be a start:

sudo tcpdump -i wan0 -s 1500 -vvv port bootps or port bootpc

If multi_interface_roam is taking the interface up and down, that may disrupt tcpdump. In that case, you'll have to play with the interface parameter. Maybe try -i any or look into the packet tap interface options.

It may also be worth doing the same packet dump on your DHCP server, and possibly the DHCP relay if you have one in your network, to see if they're processing DHCP requests properly. It's probably also worth looking at the DHCP logs if you can get to them.

EDIT2:

This turned out to be a non-confirming DHCP server that wasn't replying with the transaction ID (XID) that the client sent. I guess most clients don't care about this, but the PR2's DHCP implementation seems to.

We fixed it by giving the wan port on the PR2 a static IP address by doing the following:

In /etc/network/interfaces

auto wan0
iface wan0 inet static
  address 10.0.0.42
  netmask 255.255.255.0
  gateway 10.0.0.1

And in /etc/sysros/wifi/pr2.yaml

redirect_console: True
wireless_namespace: 'ddwrt'
wpa_config: "/etc/sysros/wifi/networks.conf" 
base_station: "basestation-novpn"
ping_port: 1194
tunnel_interface: 'tun9'
local_networks: [ '10.68.0.0/24', '10.69.0.0/24' ]
reliability_threshold: 50

interfaces:
  "basestation-novpn@wan0": { type: static, name: bs@wan0,  priority: 20 }
  "basestation-local2@lan1": { type: static, name: bs@lan1, priority: 30 }
  "wifi-router@lan0": { type: static, name: ddwrt }
# Uncomment these to make enable dual ralinks:
#  wlan0: { type: wireless }
#  wlan1: { type: wireless }