|
Boangoat Jarupan
|
dhcp.client IP request problem
|
|
Boangoat Jarupan
10/04/2012 5:51 PM
post96045
|
dhcp.client IP request problem
wireless chip: TI WL1281Q
We have problem getting IP address from AP using dhcp.client. Our board can successfully connect to the server using
wpa_supplicant. After the connection, we run "dhcp.client" to obtain the IP address from the server. When the AP is far
away (this is a main server with internet access), the station could not get the IP address to assign to the node. On
the other hand, dpch.client works fine when the AP is closed to the node within a single hop and does not have the
internet access.
We include log info in the attachment (dhcp_dump.txt) with four different logs.
1. TCPDUMP: connecting to AP_far
2. Sloginfo: connecting to AP_far
3. TCPDUMP: connecting to AP_near
4. Sloginfo: connecting to AP_near
The first two logs show the connection to far away from AP, and IP requests are fail. The first log shows that the
station receives the IP address. However, when we run ifconfig command, the IP does not get assigned to the node.
Sloginfo (2nd log) shows problem with cmdQueue_SM which we are not sure what is the implication of this error. Last two
logs show successful IP request to local AP. In log 3, the arp is called after the IP is assigned. We are not sure why
the arp command is not called when AP is far and have internet access. In log 4, the new connection information is
shown in sloginfo.
|
|
|
|
|
|
Hugh Brown
|
Re: dhcp.client IP request problem
|
|
Hugh Brown
10/05/2012 10:49 AM
post96059
|
Re: dhcp.client IP request problem
I have forwarded your query to TI.
On 2012-10-04 5:51 PM, "Boangoat Jarupan" <community-noreply@qnx.com>
wrote:
>wireless chip: TI WL1281Q
>
>We have problem getting IP address from AP using dhcp.client. Our board
>can successfully connect to the server using wpa_supplicant. After the
>connection, we run "dhcp.client" to obtain the IP address from the
>server. When the AP is far away (this is a main server with internet
>access), the station could not get the IP address to assign to the node.
>On the other hand, dpch.client works fine when the AP is closed to the
>node within a single hop and does not have the internet access.
>
>We include log info in the attachment (dhcp_dump.txt) with four different
>logs.
>
>1. TCPDUMP: connecting to AP_far
>2. Sloginfo: connecting to AP_far
>3. TCPDUMP: connecting to AP_near
>4. Sloginfo: connecting to AP_near
>
>The first two logs show the connection to far away from AP, and IP
>requests are fail. The first log shows that the station receives the IP
>address. However, when we run ifconfig command, the IP does not get
>assigned to the node. Sloginfo (2nd log) shows problem with cmdQueue_SM
>which we are not sure what is the implication of this error. Last two
>logs show successful IP request to local AP. In log 3, the arp is called
>after the IP is assigned. We are not sure why the arp command is not
>called when AP is far and have internet access. In log 4, the new
>connection information is shown in sloginfo.
>
>
>
>
>
>
>_______________________________________________
>
>Technology
>http://community.qnx.com/sf/go/post96045
>To cancel your subscription to this discussion, please e-mail
>technology-networking-unsubscribe@community.qnx.com
|
|
|
|
|
|
Hugh Brown
|
Re: dhcp.client IP request problem
|
|
Hugh Brown
10/19/2012 11:49 AM
post96470
|
Re: dhcp.client IP request problem
Just to let you know that I'm still waiting for a response from TI.
On 2012-10-04 5:51 PM, "Boangoat Jarupan" <community-noreply@qnx.com>
wrote:
>wireless chip: TI WL1281Q
>
>We have problem getting IP address from AP using dhcp.client. Our board
>can successfully connect to the server using wpa_supplicant. After the
>connection, we run "dhcp.client" to obtain the IP address from the
>server. When the AP is far away (this is a main server with internet
>access), the station could not get the IP address to assign to the node.
>On the other hand, dpch.client works fine when the AP is closed to the
>node within a single hop and does not have the internet access.
>
>We include log info in the attachment (dhcp_dump.txt) with four different
>logs.
>
>1. TCPDUMP: connecting to AP_far
>2. Sloginfo: connecting to AP_far
>3. TCPDUMP: connecting to AP_near
>4. Sloginfo: connecting to AP_near
>
>The first two logs show the connection to far away from AP, and IP
>requests are fail. The first log shows that the station receives the IP
>address. However, when we run ifconfig command, the IP does not get
>assigned to the node. Sloginfo (2nd log) shows problem with cmdQueue_SM
>which we are not sure what is the implication of this error. Last two
>logs show successful IP request to local AP. In log 3, the arp is called
>after the IP is assigned. We are not sure why the arp command is not
>called when AP is far and have internet access. In log 4, the new
>connection information is shown in sloginfo.
>
>
>
>
>
>
>_______________________________________________
>
>Technology
>http://community.qnx.com/sf/go/post96045
>To cancel your subscription to this discussion, please e-mail
>technology-networking-unsubscribe@community.qnx.com
|
|
|
|
|
|
Hugh Brown
|
Re: dhcp.client IP request problem
|
|
Hugh Brown
10/22/2012 11:51 AM
post96518
|
Re: dhcp.client IP request problem
Please can you do the following:
It would be better if they dumped the entire frame so that we can see the
contents of the DHCP packets, but for the 'far' example, it is incomplete
as there is no DHCP ACK from the server if we got that far, as I can't see
what the client sent.
Client -> discover
Server -> offer
Client -> request
Server -> ACK
There is only one reply from the server, so it appears the ACK is missing,
so the protocol exchange was never completed. Whether the client is
sending the REQUEST after the server OFFER is unclear as not enough of the
frame length is captured.
The ARP exchange is a final sanity done by dhcp.client to verify the
address is not already in use. This happens after the server ACK, but
before the IP address is assigned to the interface.
At this point it looks like traffic is dropped in the far case. A packet
sniff on both the client and AP should give an idea of what each host is
able to see.
On 2012-10-04 5:51 PM, "Boangoat Jarupan" <community-noreply@qnx.com>
wrote:
>wireless chip: TI WL1281Q
>
>We have problem getting IP address from AP using dhcp.client. Our board
>can successfully connect to the server using wpa_supplicant. After the
>connection, we run "dhcp.client" to obtain the IP address from the
>server. When the AP is far away (this is a main server with internet
>access), the station could not get the IP address to assign to the node.
>On the other hand, dpch.client works fine when the AP is closed to the
>node within a single hop and does not have the internet access.
>
>We include log info in the attachment (dhcp_dump.txt) with four different
>logs.
>
>1. TCPDUMP: connecting to AP_far
>2. Sloginfo: connecting to AP_far
>3. TCPDUMP: connecting to AP_near
>4. Sloginfo: connecting to AP_near
>
>The first two logs show the connection to far away from AP, and IP
>requests are fail. The first log shows that the station receives the IP
>address. However, when we run ifconfig command, the IP does not get
>assigned to the node. Sloginfo (2nd log) shows problem with cmdQueue_SM
>which we are not sure what is the implication of this error. Last two
>logs show successful IP request to local AP. In log 3, the arp is called
>after the IP is assigned. We are not sure why the arp command is not
>called when AP is far and have internet access. In log 4, the new
>connection information is shown in sloginfo.
>
>
>
>
>
>
>_______________________________________________
>
>Technology
>http://community.qnx.com/sf/go/post96045
>To cancel your subscription to this discussion, please e-mail
>technology-networking-unsubscribe@community.qnx.com
|
|
|
|
|
|
Boangoat Jarupan
|
Re: dhcp.client IP request problem
|
|
Boangoat Jarupan
11/07/2012 4:47 PM
post96970
|
Re: dhcp.client IP request problem
It seems like the server does not response to the DHCP DISCOVER packet from the client in "far" case. I have tried to
capture the packets and found that the TTL in IP header is set to 1. Should we set this to higher value so that the
DISCOVER packet could forward by relay agent? Are there anyway we can change this value using command line? Something
like sysctl. Unfortunately, I tried net.inet.ip.ttl, but it returns 64.
# sysctl net.inet.ip.ttl
net.inet.ip.ttl = 64
|
|
|
|
|
|
Hugh Brown
|
Re: dhcp.client IP request problem
|
|
Hugh Brown
11/08/2012 9:59 AM
post96990
|
Re: dhcp.client IP request problem
We would have to check versions, it should be going out as 64. That said,
if we are still dealing with a range issue, The TTL should be treated the
same in either case, unless we are talking about two different network
setups that are being connected to. It would still be good to see complete
packet traces as well, as it seemed like the DHCP discover was not being
ignored, it was just the 4 way handshake did not complete. The complete
packet trace would confirm this.
On 2012-11-07 4:47 PM, "Boangoat Jarupan" <community-noreply@qnx.com>
wrote:
>It seems like the server does not response to the DHCP DISCOVER packet
>from the client in "far" case. I have tried to capture the packets and
>found that the TTL in IP header is set to 1. Should we set this to higher
>value so that the DISCOVER packet could forward by relay agent? Are there
>anyway we can change this value using command line? Something like
>sysctl. Unfortunately, I tried net.inet.ip.ttl, but it returns 64.
>
># sysctl net.inet.ip.ttl
>net.inet.ip.ttl = 64
>
>
>
>
>
>
>_______________________________________________
>
>Technology
>http://community.qnx.com/sf/go/post96970
>To cancel your subscription to this discussion, please e-mail
>technology-networking-unsubscribe@community.qnx.com
|
|
|
|
|
|
Hugh Brown
|
Re: dhcp.client IP request problem
|
|
Hugh Brown
11/08/2012 10:21 AM
post96992
|
Re: dhcp.client IP request problem
Apparently we do set the TTL to 1 as it is a broadcast packet. The fact
that you get a response to the first packet indicates that you are
communicating. Are you in a noisy WiFi environment? The dhcp.client does
have a back-off timer, so if you leave it running for a while, do you
eventually get an IP address?
On 2012-11-07 4:47 PM, "Boangoat Jarupan" <community-noreply@qnx.com>
wrote:
>It seems like the server does not response to the DHCP DISCOVER packet
>from the client in "far" case. I have tried to capture the packets and
>found that the TTL in IP header is set to 1. Should we set this to higher
>value so that the DISCOVER packet could forward by relay agent? Are there
>anyway we can change this value using command line? Something like
>sysctl. Unfortunately, I tried net.inet.ip.ttl, but it returns 64.
>
># sysctl net.inet.ip.ttl
>net.inet.ip.ttl = 64
>
>
>
>
>
>
>_______________________________________________
>
>Technology
>http://community.qnx.com/sf/go/post96970
>To cancel your subscription to this discussion, please e-mail
>technology-networking-unsubscribe@community.qnx.com
|
|
|
|
|
|
Hugh Brown
|
Re: dhcp.client IP request problem
|
|
Hugh Brown
11/08/2012 10:24 AM
post96994
|
Re: dhcp.client IP request problem
Further to my last e-mail, we need to know what version of io-pkt you are
running as the old io-pkt sets the TTL to 1 but the 6.5.0 SP1 io-pkt sets
the TTL to 64.
On 2012-11-07 4:47 PM, "Boangoat Jarupan" <community-noreply@qnx.com>
wrote:
>It seems like the server does not response to the DHCP DISCOVER packet
>from the client in "far" case. I have tried to capture the packets and
>found that the TTL in IP header is set to 1. Should we set this to higher
>value so that the DISCOVER packet could forward by relay agent? Are there
>anyway we can change this value using command line? Something like
>sysctl. Unfortunately, I tried net.inet.ip.ttl, but it returns 64.
>
># sysctl net.inet.ip.ttl
>net.inet.ip.ttl = 64
>
>
>
>
>
>
>_______________________________________________
>
>Technology
>http://community.qnx.com/sf/go/post96970
>To cancel your subscription to this discussion, please e-mail
>technology-networking-unsubscribe@community.qnx.com
|
|
|
|
|
|
Boangoat Jarupan
|
Re: dhcp.client IP request problem
|
|
Boangoat Jarupan
11/08/2012 11:09 AM
post96998
|
Re: dhcp.client IP request problem
We use io-pkt-v4-hc on TI WL1283 chip. Below is the command we use to load the driver
# io-pkt-v4-hc -dti1283-sdc4430 sdio=2,dmatx=47,dmarx=48,irq=1003,gpio=90,irq_gpio=3
The dhcp.client does have a back-off timer and I see that the DHCP DISCOVER packet get rebroadcast. We have been running
dhcp.client for multiple times. Unfortunately we are not be able to get the IP address. Most of the time, DISCOVER
packets got ignore. We rarely received the OFFER packets back. On the other hand, other devices such as cell phone and
laptop are able to obtain the IP addresses easily from our server.
Unfortunately, we have trouble getting the trace result from tcpdump. This happens after we upgrade to CAR 2.0 alpha 5
platform. I posted the questions on CAR 2.0, but I received no response yet.
http://community.qnx.com/sf/discussion/do/listPosts/projects.qnx_car_2/discussion.garmin_qnx_car_2.topc22641
We currently capture packets from Wireshark. Would you be able to help us to get tcpdump to work? Or should I send you
packet traces results from Wireshark? Thank you.
|
|
|
|
|
|
Hugh Brown
|
Re: dhcp.client IP request problem
|
|
Hugh Brown
11/08/2012 11:47 AM
post97003
|
Re: dhcp.client IP request problem
Yes, Wireshark traces will be fine.
On 2012-11-08 11:09 AM, "Boangoat Jarupan" <community-noreply@qnx.com>
wrote:
>We use io-pkt-v4-hc on TI WL1283 chip. Below is the command we use to
>load the driver
>
># io-pkt-v4-hc -dti1283-sdc4430
>sdio=2,dmatx=47,dmarx=48,irq=1003,gpio=90,irq_gpio=3
>
>The dhcp.client does have a back-off timer and I see that the DHCP
>DISCOVER packet get rebroadcast. We have been running dhcp.client for
>multiple times. Unfortunately we are not be able to get the IP address.
>Most of the time, DISCOVER packets got ignore. We rarely received the
>OFFER packets back. On the other hand, other devices such as cell phone
>and laptop are able to obtain the IP addresses easily from our server.
>
>Unfortunately, we have trouble getting the trace result from tcpdump.
>This happens after we upgrade to CAR 2.0 alpha 5 platform. I posted the
>questions on CAR 2.0, but I received no response yet.
>http://community.qnx.com/sf/discussion/do/listPosts/projects.qnx_car_2/dis
>cussion.garmin_qnx_car_2.topc22641
>
>We currently capture packets from Wireshark. Would you be able to help us
>to get tcpdump to work? Or should I send you packet traces results from
>Wireshark? Thank you.
>
>
>
>_______________________________________________
>
>Technology
>http://community.qnx.com/sf/go/post96998
>To cancel your subscription to this discussion, please e-mail
>technology-networking-unsubscribe@community.qnx.com
|
|
|
|
|
|
Boangoat Jarupan
|
Re: dhcp.client IP request problem
|
|
Boangoat Jarupan
11/08/2012 12:26 PM
post97004
|
Re: dhcp.client IP request problem
Please find the dump in the attachment. I filter out only DHCP packets due to the size of the original dump file. Also,
please note that we use f8:7b:7a:40:89:c4 as the mac address for testing. The first DISCOVER packet starts at packet #11
and it is from our board. In this dump, there is no response from the server. We have tried many times; unfortunately,
we can not get any response from the server.
I am also wondering whether this problem is related to relay agent for DHCP server. What do we need to do to check that
possibility?
Thank you.
|
|
|
|
|
|
