Marsi4eg
Regular Contributor
I have got a PS2 console recently and faced some problem with network functions using AC66U router. The problem is that router just ignores dhcp-discover packets from the console. I have tried a couple of default firmwares, some older Asuswrt-Merlin releases and Merlin forks - and nothing on all of them.
I was sure that the problem is with PS2 or with badly coded homebrew that uses dhcp client functionality. Even 'bugreported' this on those forums (http://ps2home.freeforums.net/thread/319/having-issue-dhcp?page=1&scrollTo=6734).
The main interesting thing I got from that topic - all three bugreports was from people with RT-N56U, AC66R and AC66U (me). That made me curious and I decided to begin some deep investigation.
Being a worker of ISP I had an ability to do a simple test of PS2 connection directly to ISP's network without the router. I was very surprised when our ISP's DHCP server accepted Discover packet and assigned an IP to console:
I decided to continue testing with some other routers and plugged in very-very old Dlink DI-624. And it also didn't ignore a discover packet from PS2 and successfully assigned the IP.
After that I have tested the same thing on my RT-N16 with the last Merlin firmware (378.50) and it didn't ignore Discover and assigned IP!
So, console was tested with four different DHCP servers and only AC66U's dnsmasq-dhcp ignores Discover packet from it. Also I tried an options with static leases enabled, disabled. Had to reset router to factory defaults and that also didn't help.
Now, to make sure that console 100% sends Discover packet, I used some Wireshark to capture dhcp broadcasting and got it:
Maybe something of this will help to know a reason of dropping or just ignoring this packet by AC66U dnsmasq.
Thanks
I was sure that the problem is with PS2 or with badly coded homebrew that uses dhcp client functionality. Even 'bugreported' this on those forums (http://ps2home.freeforums.net/thread/319/having-issue-dhcp?page=1&scrollTo=6734).
The main interesting thing I got from that topic - all three bugreports was from people with RT-N56U, AC66R and AC66U (me). That made me curious and I decided to begin some deep investigation.
Being a worker of ISP I had an ability to do a simple test of PS2 connection directly to ISP's network without the router. I was very surprised when our ISP's DHCP server accepted Discover packet and assigned an IP to console:
Code:
2016-03-12 20:48:09 DISCOVER: [00:15:c1:f6:03:86] via (192.168.34.24) 2882338817
2016-03-12 20:48:09 OFFER: [00:15:c1:f6:03:86] 10.2.151.166 2882338817
2016-03-12 20:48:09 REQUEST: [00:15:c1:f6:03:86] via (192.168.34.24) 2882338818
2016-03-12 20:48:09 ACK: [00:15:c1:f6:03:86] 10.2.151.166 2882338818I decided to continue testing with some other routers and plugged in very-very old Dlink DI-624. And it also didn't ignore a discover packet from PS2 and successfully assigned the IP.
After that I have tested the same thing on my RT-N16 with the last Merlin firmware (378.50) and it didn't ignore Discover and assigned IP!
So, console was tested with four different DHCP servers and only AC66U's dnsmasq-dhcp ignores Discover packet from it. Also I tried an options with static leases enabled, disabled. Had to reset router to factory defaults and that also didn't help.
Now, to make sure that console 100% sends Discover packet, I used some Wireshark to capture dhcp broadcasting and got it:
Code:
34140 306.891275 169.254.0.1 255.255.255.255 DHCP 350 DHCP Discover - Transaction ID 0xabcd0006
Frame 34140: 350 bytes on wire (2800 bits), 350 bytes captured (2800 bits) on interface 0
Interface id: 0 (\Device\NPF_{B1E0F717-50C5-48D5-AACD-C61585957630})
Encapsulation type: Ethernet (1)
Arrival Time: Mar 14, 2016 02:07:29.567577000 RTZ 2 (����)
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1457910449.567577000 seconds
[Time delta from previous captured frame: 0.041971000 seconds]
[Time delta from previous displayed frame: 0.041971000 seconds]
[Time since reference or first frame: 306.891275000 seconds]
Frame Number: 34140
Frame Length: 350 bytes (2800 bits)
Capture Length: 350 bytes (2800 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:udp:bootp]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Ethernet II, Src: SonyComp_f6:03:86 (00:15:c1:f6:03:86), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Source: SonyComp_f6:03:86 (00:15:c1:f6:03:86)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 169.254.0.1, Dst: 255.255.255.255
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
Total Length: 336
Identification: 0x0053 (83)
Flags: 0x00
Fragment offset: 0
Time to live: 255
Protocol: UDP (17)
Header checksum: 0x104b [validation disabled]
Source: 169.254.0.1
Destination: 255.255.255.255
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 68 (68), Dst Port: 67 (67)
Source Port: 68
Destination Port: 67
Length: 316
Checksum: 0x0111 [validation disabled]
[Stream index: 42]
Bootstrap Protocol (Discover)
Message type: Boot Request (1)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0xabcd0006
Seconds elapsed: 0
Bootp flags: 0x0000 (Unicast)
0... .... .... .... = Broadcast flag: Unicast
.000 0000 0000 0000 = Reserved flags: 0x0000
Client IP address: 0.0.0.0
Your (client) IP address: 0.0.0.0
Next server IP address: 0.0.0.0
Relay agent IP address: 0.0.0.0
Client MAC address: SonyComp_f6:03:86 (00:15:c1:f6:03:86)
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type (Discover)
Length: 1
DHCP: Discover (1)
Option: (57) Maximum DHCP Message Size
Length: 2
Maximum DHCP Message Size: 1500
Option: (55) Parameter Request List
Length: 4
Parameter Request List Item: (1) Subnet Mask
Parameter Request List Item: (3) Router
Parameter Request List Item: (28) Broadcast Address
Parameter Request List Item: (6) Domain Name Server
Option: (255) End
Option End: 255
Padding: 000000000000000000000000000000000000000000000000...Maybe something of this will help to know a reason of dropping or just ignoring this packet by AC66U dnsmasq.
Thanks
Last edited:
