Starting Nov 29 04:16:10 I start seeing a new error in my /v/l/messages from dhclient (the DHCP client for my Shaw internet connection):
Nov 29 04:16:10 pog dhclient[1271]: parse_option_buffer: malformed option dhcp.fqdn (code 81): option length exceeds option buffer length.
And it repeats every 30-39s for hours, then sometimes stops for a while. Sometimes skips a day but then starts up again.
Is someone trying a known DHCP buffer overflow attack on my Shaw segment or is this something legit that Shaw is passing out that linux doesn't understand? I know what fqdn means, though why it should exceed buffer limits is beyond me.
Can others check their logs and see if they're getting this too?
There was 1 other weird dhclient error before this started: Nov 27 06:52:55 pog dhclient[1271]: parse_option_buffer: malformed option dhcp.uap-servers (code 98): option length exceeds option buffer length.
That's a strange issue - which version of dhclient is it? Shaw may be doing something creative on their network that dhclient needs to be configured more openly to accept.
Also, Trevor, you're alive! I had sent a few e-mails to different addresses when organizing the bad capacitor night at Skullspace and assumed you had been absorbed into the tubes.
On 12/5/12, Trevor Cordes trevor@tecnopolis.ca wrote:
Starting Nov 29 04:16:10 I start seeing a new error in my /v/l/messages from dhclient (the DHCP client for my Shaw internet connection):
Nov 29 04:16:10 pog dhclient[1271]: parse_option_buffer: malformed option dhcp.fqdn (code 81): option length exceeds option buffer length.
And it repeats every 30-39s for hours, then sometimes stops for a while. Sometimes skips a day but then starts up again.
Is someone trying a known DHCP buffer overflow attack on my Shaw segment or is this something legit that Shaw is passing out that linux doesn't understand? I know what fqdn means, though why it should exceed buffer limits is beyond me.
Can others check their logs and see if they're getting this too?
There was 1 other weird dhclient error before this started: Nov 27 06:52:55 pog dhclient[1271]: parse_option_buffer: malformed option dhcp.uap-servers (code 98): option length exceeds option buffer length. _______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
On 2012-12-05 Colin Stanners wrote:
That's a strange issue - which version of dhclient is it?
F16's dhclient-4.2.4-4.P2.fc16.i686 Should be pretty recent.
Also, Trevor, you're alive! I had sent a few e-mails to different addresses when organizing the bad capacitor night at Skullspace and assumed you had been absorbed into the tubes.
Sorry! I had my other business stuff takeover all my time and had to ignore the cap repair requests for a while. Are you going to MUUG meetings now? Say hi at the next meeting, ask any of the board, they can point me out. I'm still into the cap repair in a big way and stock nearly every value at all times. Not just mobos anymore either now that nearly everything made has badcaps.
I've seen it a couple of times:
/var/log/messages-20121111:Nov 10 21:35:17 bob dhclient[1114]: parse_option_buffer: malformed option dhcp.<unknown> (code 105): option length exceeds option buffer length. /var/log/messages-20121118:Nov 16 22:02:35 bob dhclient[1114]: parse_option_buffer: malformed option dhcp.slp-service-scope (code 79): option length exceeds option buffer length. /var/log/messages-20121125:Nov 21 22:48:13 bob dhclient[1114]: parse_option_buffer: malformed option dhcp.slp-service-scope (code 79): option length exceeds option buffer length.
I'm on 24.77.240.0/22
Sean
On Wed, Dec 5, 2012 at 6:51 AM, Trevor Cordes trevor@tecnopolis.ca wrote:
Starting Nov 29 04:16:10 I start seeing a new error in my /v/l/messages from dhclient (the DHCP client for my Shaw internet connection):
Nov 29 04:16:10 pog dhclient[1271]: parse_option_buffer: malformed option dhcp.fqdn (code 81): option length exceeds option buffer length.
And it repeats every 30-39s for hours, then sometimes stops for a while. Sometimes skips a day but then starts up again.
Is someone trying a known DHCP buffer overflow attack on my Shaw segment or is this something legit that Shaw is passing out that linux doesn't understand? I know what fqdn means, though why it should exceed buffer limits is beyond me.
Can others check their logs and see if they're getting this too?
There was 1 other weird dhclient error before this started: Nov 27 06:52:55 pog dhclient[1271]: parse_option_buffer: malformed option dhcp.uap-servers (code 98): option length exceeds option buffer length. _______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
On 2012-12-05 Sean Walberg wrote:
I've seen it a couple of times:
/var/log/messages-20121111:Nov 10 21:35:17 bob dhclient[1114]: parse_option_buffer: malformed option dhcp.<unknown> (code 105): option length exceeds option buffer length.
I'm on 24.77.240.0/22
I did a packet cap and wireshark to view. Something very weird is going on here. Wireshark says the DHCP packets at the time of error are malformed.
It's from 50.72.224.1, which appears to be a Shaw router? I'm on a 50.72 network. It doesn't appear to be the normal Shaw DHCP server.
The packet is 50.72.224.1:67 to 255.255.255.255:68, 308 bytes
It's telling me my client IP is <insert not my ip here> "Relay agent" 50.72.224.1 (same as above) client mac: AsustekC brand (hmmmm...)
It gets cutoff in the middle of the fqdn option, hence probably the malformation and /v/l/messages error.
So my guess now is probably some nitwit has a DHCP server working the Shaw network side rather than their internal side? Or maybe a deliberate hack attempt to hand out bogus IPs?
Sucks that it has to fill my logs with 648 errors so far today...
On Wed, Dec 5, 2012 at 11:59 AM, Trevor Cordes trevor@tecnopolis.ca wrote:
The packet is 50.72.224.1:67 to 255.255.255.255:68, 308 bytes
But is it to your MAC address or not?
So my guess now is probably some nitwit has a DHCP server working the Shaw network side rather than their internal side? Or maybe a deliberate hack attempt to hand out bogus IPs?
The router is probably not the DHCP server, it's just the forwarder for a backend management system. My guess is that our AsustekC friend is making a request with a strange option 81 that's being blindly copied in the response and since DHCP is a broadcast at this point, you're seeing it.
Sean
On 2012-12-05 Sean Walberg wrote:
On Wed, Dec 5, 2012 at 11:59 AM, Trevor Cordes trevor@tecnopolis.ca wrote:
The packet is 50.72.224.1:67 to 255.255.255.255:68, 308 bytes
But is it to your MAC address or not?
The ethernet layer is of course bc'ing to ff:ff:ff:ff:ff:ff
The DHCP packet is showing a client MAC address that's the AsustekC, and it's not my MAC.
The router is probably not the DHCP server, it's just the forwarder for a backend management system.
Ya, looks like it.
My guess is that our AsustekC friend is making a request with a strange option 81 that's being blindly copied in the response and since DHCP is a broadcast at this point, you're seeing it.
Hmm, I'm not sure I follow... been up too long! Not sure why Shaw's routers would relay bc's across subnets sourced from random nitwit's broken client/router? This is type "Boot Reply (2)" which should be coming from the DHCP server back to the client?
On Wed, Dec 5, 2012 at 12:31 PM, Trevor Cordes trevor@tecnopolis.ca wrote:
Hmm, I'm not sure I follow... been up too long! Not sure why Shaw's routers would relay bc's across subnets sourced from random nitwit's broken client/router? This is type "Boot Reply (2)" which should be coming from the DHCP server back to the client?
I'd be interested to see the packet.
At least with ARPs you see all sorts of subnet leakage. Do a "tcpdump arp" some day and watch for stuff that doesn't belong, most of it comes from Shaw routers.
Sean
My random guess is that their DHCP server is sending out DHCP packets that are bigger (these days) than their routers are used to forwarding for DHCP-relay. How big are the packets?
On 12/5/12, Sean Walberg sean@ertw.com wrote:
On Wed, Dec 5, 2012 at 12:31 PM, Trevor Cordes trevor@tecnopolis.ca wrote:
Hmm, I'm not sure I follow... been up too long! Not sure why Shaw's routers would relay bc's across subnets sourced from random nitwit's broken client/router? This is type "Boot Reply (2)" which should be coming from the DHCP server back to the client?
I'd be interested to see the packet.
At least with ARPs you see all sorts of subnet leakage. Do a "tcpdump arp" some day and watch for stuff that doesn't belong, most of it comes from Shaw routers.
Sean
-- Sean Walberg sean@ertw.com http://ertw.com/
The ARP stuff that doesn't belong may be for backwards compatibility with old IP ranges/designs...
Anyone remember when Shaw or Videon was transitioning to a new IP range, if you manually configured your machine for any static IP on the old range it would work? Some people did that for lower latency to the UofM/MTS since the old network connected in Wpg but the new network went to their IXes in Calgary/Toronto/etc. before geting on to the internet.
On 12/5/12, Sean Walberg sean@ertw.com wrote:
On Wed, Dec 5, 2012 at 12:31 PM, Trevor Cordes trevor@tecnopolis.ca wrote:
Hmm, I'm not sure I follow... been up too long! Not sure why Shaw's routers would relay bc's across subnets sourced from random nitwit's broken client/router? This is type "Boot Reply (2)" which should be coming from the DHCP server back to the client?
I'd be interested to see the packet.
At least with ARPs you see all sorts of subnet leakage. Do a "tcpdump arp" some day and watch for stuff that doesn't belong, most of it comes from Shaw routers.
Sean
-- Sean Walberg sean@ertw.com http://ertw.com/
-
Colin Stanners -
Sean Walberg -
Trevor Cordes